On Fri, Apr 27, 2012 at 04:48:37PM -0400, Mike Frysinger wrote: > On Friday 27 April 2012 14:48:11 Bernhard Reutner-Fischer wrote: > > On 3 March 2012 05:24, Ismael Luceno <ismael.luc...@gmail.com> wrote: > > > Signed-off-by: Ismael Luceno <ismael.luc...@gmail.com> > > > --- > > > extra/Configs/Config.in | 7 + > > > include/spawn.h | 266 > > > librt/Makefile.in > > > librt/spawn.c | 251 > > > librt/spawn_faction_addclose.c | > > > librt/spawn_faction_adddup2.c | 52 ++++++++ > > > librt/spawn_faction_addopen.c | 55 ++++++++ > > > librt/spawn_faction_init.c | 42 +++++++ > > > librt/spawn_int.h | 26 ++++ > > > > And what was the rational to add this to librt instead of libc? > > it's "advanced realtime" funcs, and librt is the "realtime library". > although > i guess glibc sticks them in libc which is what you're asking about. > -mike
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. 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. Busybox even has a nasty workaround for this, making the clock_gettime syscall directly to avoid librt. 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? Rich _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc