[uClibc]Re: proposal -- feedback requested

[Manuel Novoa III]

On Tue, 23 Jan 2001, Erik Andersen wrote:
> > Right now there are certain "problem headers" in uClibc/linux that test for the
> > macro __GLIBC__ and it value, and modify their behavior based on that.
> > For 2.2.19pre7, find /usr/include/linux/ -name "*.h" | xargs grep __GLIBC__
> > gives:
> > (stuff deleted)
>
> This is certainly a problem, and your method is certainly a sane one, i.e
> carefully building up wrappers for all the kernel headers.  

Not all... only the few that cause problems.

> Just for the sake of argument, to make sure we look at both of the possible
> solutions, I wonder if we might be better served by simply selling-out and
> deliberately lying.  For example, what sort of problems are we likely to run
> into if we add something like this to include/features.h:
> 
>     /*  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 these apps work as their
> 	developers intended.  This is IMHO, pardonable, since these defines
> 	are really intended to check for the presence of an interface, not a 
> 	particular library per se...  */

At first, I thought about doing this.  But what if the interface being checked
for is one we either haven't implemented or decided _not_ to implement?
Also, the wrapper approach allows us to do tuning of particular problem headers;
something that might be necessary at various times in uClibc's evolution.

> I suspect that in the long run, this will probably cause more good the harm.
> So it really comes down to a question of how pure we want to be.  I know for
> busybox, I already had to modify it in several places to do
>     #if defined(__GLIBC__) || defined (__UCLIBC__)
> if we spread effort across about a zillion apps, I think that simply lying about
> our name may end up serving us better.  

I'm kind of on-the-fence about it.  We're just getting to the point where we
can successfully build some large packages.  With so little experience, I hate
to commit one way or the other.

We might take a hybrid approach.  We could do the wrappers and add an option
to gcc-uClibc called --impersonate-glibc (or some such) which would
define __GLIBC__ and __GLIBC_MINOR__ to be whatever was appropriate.  Of
course, the wrappers would then just pass through to the real headers.  Or, if
we wanted impersionation to be the default, change the option to
--do-not-impersonate-glibc.

> > On a related topic, I'd like to generate a header file describing the
> > build-time configurate of uClibc that apps can check.  I was thinking of
> > uClibc/include/uClibc_config.h?  Again, I'm open to suggestions for a name.
> 
> works for me.

Ok.

Manuel