[PATCHv3] librt: Add posix_spawn support

Mike Frysinger vapier at gentoo.org
Fri Apr 27 23:35:11 UTC 2012


On Friday 27 April 2012 18:33:08 Rich Felker wrote:
> Why does librt still exist as a non-empty library? The only original
> explanation I can think of is that, historically, it replaced some
> functions in libc with versions that needed to behave specially for
> compatibility with advanced realtime requirements.

for some funcs, like mq_* and aio_* and lio_*, very few apps use them.  so 
avoiding having them mapped in all the time is a good thing.

librt also links against libpthread.  i'd have to dig into the source/spec as 
to why glibc made that a requirement vs the normal libc forwarding pthread 
stubs.

> But nowadays it's
> just really annoying and harmful. With shared libraries, it adds bloat
> and load time to every program which wants to use clock_gettime for
> getting system time, which is every modern program.

i'd side with the clock_* funcs being better in libc because they are getting 
used more and more as people transition away from gettimeofday()

> Busybox even has a nasty workaround for this, making the clock_gettime
> syscall directly to avoid librt.

that's not really uClibc's fault.  glibc does this too.  and i find it hard to 
believe they couldn't just test -lrt ... after all, they do it with -lm 
already.

> Is anybody really opposed to just making librt.a empty, librt.so
> nonexistent, and putting all the functions in libc.a/libc.so where
> they belong?

it would be really cool if we could split lesser used and standalone code into 
standalone shared libraries and libc.so was a simple linker script that pulled 
in all the other objects AS_NEEDED(...).  but alas, that'd play havoc with 
ABI/SONAMEs.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120427/cf5bc39f/attachment.asc>


More information about the uClibc mailing list