Re: skalibs: how to properly detect posix_spawnp() when using uclibc-ng?

From: Eric Le Bihan <eric.le.bihan.dev_at_free.fr>
Date: Fri, 12 Aug 2016 10:30:06 +0200

Hi!

Le Wed, 10 Aug 2016 21:29:36 +0200,
Laurent Bercot <ska-skaware_at_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
Received on Fri Aug 12 2016 - 08:30:06 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC