On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote: > 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.
That's a decent reason for keeping it separate (at least as long as libpthread is separate), but then it should only contain the stuff that depends on pthread, not clock_gettime, etc. And of course the stuff that depends on pthread could just be merged into libpthread.so... > > 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() And they are NOT part of any optional realtime option in POSIX; they're a mandatory part of POSIX base. > > 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. I believe the idea is to avoid pulling in librt.so because it makes things a lot more bloated. (Several extra dirty pages for another .so, plus the time to find/map/relocate it.) > > 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 I don't understand how this is all that useful. If you have binaries on your system that use standard functionality X, you'll have to have it _somewhere_ anyway, and it might as well be in libc.so. If you're worried about rare functions being spread out across lots of pages that might also contain widely-used functions and increasing average paged-in memory usage, it would be possible to add section attributes to all the rare stuff to put it all in one contiguous part of libc.so that would only be paged-in when stuff is actually using it. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
