On 03/22/2011 06:53 PM, Mike Frysinger wrote: >>> heh so you mean whatever glibc does is right ? >> >> If the package is expecting something specifically because we're >> exporting _GLIBC_? Yes. > > which is a compatibility hack intended to go away.
And yet it hasn't, and there's no CONFIG entry to test without it. > if you want to > actually *fix* things, start building packages without uClibc > exporting those compat defines. > -mike Apparently uClibc itself has checks for __GLIBC__ in libc/unistd/getopt.c and extra/config/zconf.tab.c. (The second one is the FSF's bison output: if they're not using glibc then they make their own strlen() using a for loop. That's taking not invented here to new levels, but they always were a xenophobic lot...) For some reason uClibc is #defining __GLIBC__ in bits/socket.h, but I don't see that in any checks for that in the kernel's assembly code. (Ok, it shows up in arch/mn10300/include/asm/posix_types.h but that doesn't count.) Possibly this is support for the 7 year old 2.4 series? (Is there still any reason to support that? Are we going to wait for the 10th anniversary of 2.6 to drop support for 2.4?) So I assume you're referring to the export in include/features.h under the comment: /* There is an unwholesomely huge amount of code out there that depends on the presence of GNU libc header files. We have GNU libc header files. So here we commit a horrible sin. At this point, we _lie_ and claim to be GNU libc to make things like /usr/include/linux /socket.h and lots of apps work as their developers intended. This is IMHO, pardonable, since these defines are not really intended to check for the presence of a particular library, but rather are used to define an _interface_. */ That comment is just over 10 years old, and says that the policy of uClibc is "these define an interface". So my position was that in the previous version we _were_ implementing this interface (with a trivial patch to uClibc that didn't touch any third party code), the current version is not, and that this is an obvious regression. Your position is that at some unknown point in the future some unnamed person is going to change how uClibc does stuff and retest everything, and in the meantime we should start polluting third party packages with #ifdef uClibc to work around... this obvious regression. Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
