On Friday 27 April 2012 19:59:34 Rich Felker wrote: > On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote: > > On Friday 27 April 2012 18:33:08 Rich Felker wrote: > > > 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.
afaik, POSIX doesn't cover library layout in any way. there is nothing requiring us to stick all mandatory interfaces into -lc. after all, much of the math support falls into this category yet lives in -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 ABI/SONAMEs. > > 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. not everyone have virtual memory :p. ignoring that, larger single libraries means more reloc processing at init, and more string space to search when resolving symbols. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc