Can't build m4 or bison with -rc3.

Rob Landley rob at landley.net
Wed Mar 23 00:24:52 UTC 2011


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


More information about the uClibc mailing list