[PATCHv3] librt: Add posix_spawn support
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
> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc