Can't build m4 or bison with -rc3.

Mike Frysinger vapier at gentoo.org
Wed Mar 23 00:34:47 UTC 2011


On Tue, Mar 22, 2011 at 8:24 PM, Rob Landley wrote:
> 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.

here's an idea ... submit patches that are correct so they can be merged

> 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?

no, it took quite a while for linux's socket.h to get updated.  try
reading linux's git history.  it was only removed in 2.6 at the end
2009.

linux's stat.h is still fucked up, and attempts to fix it have hit
stupid developers.

> 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.

that's nice that you think that.  good thing i dont care.  help out
fixing the actual problems such as the need for __GLIBC__ in the first
place.
-mike


More information about the uClibc mailing list