svn commit: branches/uClibc-nptl: libc/sysdeps/linux/common libpthread/lin etc...

Denys Vlasenko vda.linux at googlemail.com
Thu Feb 26 16:06:05 UTC 2009


On Thursday 26 February 2009 03:14:18 pm Bernd Schmidt wrote:
> Bernhard Reutner-Fischer wrote:
> > On Wed, Feb 25, 2009 at 03:21:34PM +0100, Bernd Schmidt wrote:
> >> Denys Vlasenko wrote:
> >>> On Wednesday 25 February 2009 01:31:01 pm Bernd Schmidt wrote:
> >>>> vda at uclibc.org wrote:
> >>>>> reinstate __libc_foo for linuxthreads.old
> >>>> The code didn't seem to have the awful #ifdefs before your checkins
> >>>> 24362 and 24363.  I think it's a terrible idea to add more differences
> >>>> between pthreads versions like this.
> >>> Without ifdefs, __libc_foo's will exist even in non-threaded builds.
> >>> I prefer this to not happen. I feel it is cleaner to minimize
> >>> the number of non-standard names being exported.
> >> Anything starting with a double underscore is in the libc namespace, so
> >> this isn't something we need to worry about.
> > 
> > Well for cleanness it is preferable not to export "artificial" symbols
> > that are not mandated by a sensible standard iff it is a voidable.
> 
> What exactly is the problem with it?  It can't affect anything since
> user programs aren't allowed to use these names.

But they do. libc/sysdeps/linux/common/write.c says:

#if 0
/* Stupid libgcc.a from gcc 2.95.x uses __write in pure.o
 * which is a blatant GNU libc-ism... */
strong_alias(write,__write)
#endif

Another one is the hack in buildroot's gcc patch where
it blatantly used uclibc locale internals.

This is why it's best to minimize unwanted exports. No exports ->
nobody can code up dirty hacks using them.

> There's still the other issues with this patch that I mentioned.

What issues? This one?

>It means that write will change from being a strong to a weak definition
>depending on which threads library you select, which is surprising.

I don't have problem with it. Why users of non-threaded library
should be burdened by useless __libc_foo's? Why they should have
bigger than needed libc.so.0?

> Also, 
> what mechanism does linuxthreads_new use to make sure it's using the
> functions in libc, rather than something overridden by the application?

Have no idea. There is no evidence linuxthreads_new works for
any architecture. And no, I'm not going to check 12 architectures
just because you want to know it for sure. That had to be done by
the submitter of that code, at the time of submission.
Obviously, [s]he did not even test it on the most easily available
arch, x86.

--
vda


More information about the uClibc mailing list