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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
