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

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Thu Feb 26 08:38:18 UTC 2009


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.
>
>> Did it really get seriously worse? Let's compare:
>> 
>> 0.9.30:
>> 
>> extern __typeof(write) __libc_write;
>> #define __NR___libc_write __NR_write
>> _syscall3(ssize_t, __libc_write, int, fd, const __ptr_t, buf, size_t, count)
>> libc_hidden_proto(write)
>> weak_alias(__libc_write,write)
>> libc_hidden_weak(write)
>> 
>> Trunk:
>> 
>> _syscall3(ssize_t, write, int, fd, const __ptr_t, buf, size_t, count)
>> #ifndef __LINUXTHREADS_OLD__
>> libc_hidden_def(write)
>> #else
>> libc_hidden_weak(write)
>> strong_alias(write,__libc_write)
>> #endif
>
>It means that write will change from being a strong to a weak definition
>depending on which threads library you select, which is surprising.  All
>#ifdefs add the risk of bugs being added in the future since you'll
>typically only ever compile one branch.
>
>>> Besides, shouldn't these functions be weak in any case, so that the user
>>> can override them?
>> 
>> Ordinarily, libc interface functions are not weak.
>
>That's something that one of these days I'd really like a definite
>answer to.  Some gcc tests rely on being able to override certain libc
>functions.

Which tests? Do you have a sample at hand?


More information about the uClibc mailing list