Hi!

Le Wed, 10 Aug 2016 21:29:36 +0200,
Laurent Bercot <ska-skaw...@skarnet.org> a écrit :

> > The ./configure script of skalibs tries to detect if posix_spawnp()
> > is available on the system by generating a runtime test and
> > executing it.
> >
> > For whichever reason, uclibc-ng provides this function in librt.a,
> > not in libc.a. So the runtime test fails when trying to link the
> > test program.
> >
> > Adding -lrt to the command line to build the test program should
> > fix this, but how to properly do it?  
> 
>   According to
>   http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
> putting the spawn.h functions in librt is valid, so uclibc-ng is
> conforming and my autodetection is incorrect. I need to fix the
> configure script.
> 
>   This is annoying, because uclibc-ng's (and glibc's, too) librt
> depends on libpthread. That means, among other things, that if you
> link dynamically, you will pull in libpthread.so, and use thread-safe
> functions even if your program is single-threaded. Why didn't
> uclibc-ng do away with that historical ugliness?

As explained in the discussion about the original patch to include
these functions [1]:

  it's "advanced realtime" funcs, and librt is the "realtime library".

>   The best solution, of course, is to mark uClibc and all its breed as
> obsolescent, and encourage users to switch to musl. :P

Before the advent of uclibc-ng, Buildroot was considering switching by
default to glibc [2], as the old uclibc project was dead and Buildroot
shipped zillions of patches for it. Using musl was evoked, but uclibc-ng
is still preferred, as it supports non-MMU architectures and Buildroot
is about embedded devices.

[1] http://lists.busybox.net/pipermail/uclibc/2012-April/046775.html
[2] http://lists.uclibc.org/pipermail/uclibc/2014-February/048252.html

Best regards,

-- 
ELB

Reply via email to