According to the dbus website, glibc is NOT a requirement for dbus. The ebuild tries to enforce this and fails trying to run Autoconf (or even a manual configure process) on a uclibc based system (gentoo embedded stage3). Since the docs say glibc should be a requirement, I tried the actual dbus archive without the patches supplied by Gentoo, and it runs through configure and compiles just fine. So .. one of the gentoo patches evidently breaks the ability to compile on gentoo embedded.
This ebuild suffers from quite a few problems mostly related to iconv & gettext handling. It bundles a modified copy of glib 2.0 I dont know how you got it to build without modifying quite a few things like c files and Makefiles a header and the configure file. There are also a ton of world writable dirs here. (chmod/security foo needed) embedded would be happy to revisit this pkg after the initial gettext/nls/iconv/permission handling gets fixed. Reassigning to maintainer.
i dont think theres anything here to fix dbus doesnt require glibc at all, i dont know where you get that wrong idea autoconf failing is because it needs some macro's provided by glib-2.x ... well glib-2.x doesnt work on uclibc, oh well i dont see any bundled glib files in dbus the permissions on the unpacked archive is "normal", you'll see the samething in many many other archives
Actually, I did the following ... unmasked iconv, which allowed gettext to build. I don't use nls dbus still would not compile. The version of the source that portage installs into /var/tmp just wouldn't configure. I noticed that a number of patches were applied by portage, so I erased the portage version and just decompressed the raw source tarball out of /usr/portage/distfiles, and then did a configure and make. To say "dbus doesn't require glibc at all" is kinda silly. If it doesn't require glibc, then remove glibc as a dependancy and figure out why the patches that gentoo applies stop configure from working without glibc. I don't know much about bundled files or permissions but it seems very logical that if it works without the patches, and doesn't work with the patches, then one of the patches must be the problem. How does anything get done when the maintainers constantly say "works for me, so this bug is invalid"?
> Actually, I did the following ... > unmasked iconv, which allowed gettext to build. I don't use nls iconv isnt supported under uclibc, it breaks too many things > To say "dbus doesn't require glibc at all" is kinda silly. If it doesn't > require glibc, then remove glibc as a dependancy and figure out why the > patches that gentoo applies stop configure from working without glibc. dbus does not depend on glibc, read the ebuild ... whatever is making you think that is clearly wrong
Here is how I hacked around it yesterday. I disabled nls, iconv/ and short circuited a check or two and fixed the perms. iconv was really a pain in the rear!! If somebody wanted to clean up the $FILESDIR/*nls*patch using proper AC macros that would be cool. ftp://tinderbox.x86.dev.gentoo.org/misc/dbus/
