[announce] execline mode for GNU/Emacs
Hi! For GNU/Emacs users writing execline scripts, new packages are available: - execline-mode [1]: provides syntax highlighting, automatic indentation and commands for executing a buffer, region or string as execline buffers. - company-mode [2]: provides auto-completion for builtin commands (forbacktickx, ...) For Spacemacs [3] users, a layer is also available [4]. These packages are very basic. Feedback welcome. [1] https://github.com/elebihan/execline-mode [2] https://github.com/elebihan/company-execline [3] http://spacemacs.org/ [4] https://github.com/elebihan/spacemacs-execline Regards, -- ELB
skaware programs and libraries available in Guix 0.11.0
Hi! All skaware programs and libraries are now available as packages for Guix [0], the GNU transactional package manager [1], which make them available to any GNU/Linux distribution. To play with s6 and friends, execute `guix package -i s6`. [0] https://lists.gnu.org/archive/html/guix-devel/2016-08/msg00219.html [1] https://www.gnu.org/software/guix/ Best regards, -- ELB
skalibs: how to properly detect posix_spawnp() when using uclibc-ng?
Hi! 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? a) Using `LDFLAGS="-lrt" ./configure ...` is not correct. Should a $LIBS variable be added and used in the `choose()` function of the script? b) Should linking with librt be forced in the test, even if it is unnecessary for other C runtimes? Example: choose cl posixspawn POSIXSPAWN 'posix_spawn()' -lrt Besides, how should the sysdeps be updated to add the dependency to librt, in order to avoid passing EXTRA_LIBS="-lrt" to `make` when building s6 and friends? Note that the current implementation of posix_spawnp() in uclibc is buggy. It causes child_spawn0() to loop infinitely as described here [1]. A fix has been sent upstream [2]. [1] https://www.mail-archive.com/supervision%40list.skarnet.org/msg01058.html [2] http://mailman.uclibc-ng.org/pipermail/devel/2016-August/001126.html Best regards, -- ELB
Re: skalibs: how to properly detect posix_spawnp() when using uclibc-ng?
Hi! Le Wed, 10 Aug 2016 21:29:36 +0200, Laurent Bercot 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
Re: skalibs: how to properly detect posix_spawnp() when using uclibc-ng?
Hi!
Le Wed, 10 Aug 2016 21:47:36 +0200,
Laurent Bercot a écrit :
> On 10/08/2016 21:29, Laurent Bercot wrote:
> > 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.
>
> Eric: please test building the latest skalibs git head against
> uclibc-ng and tell me if it works. In particular, I'd like to know
> whether the posix_spawn autodetection works both when your compiler
> links dynamically by default (CC=gcc) and when you force it to link
> statically (CC="gcc -static").
Unfortunately, it does not work. The modification assumes that the
check for clock_gettime() will result in $rt_lib being set to -lrt, but
it is not the case for uclibc-ng, where this function is available in
the C runtime:
```
$ nm i686-buildroot-linux-uclibc/sysroot/lib/librt-1.0.14.so \
| grep clock_gettime
2308 T clock_gettime
2308 t __GI_clock_gettime
$ nm i686-buildroot-linux-uclibc/sysroot/lib/libuClibc-1.0.14.so \
| grep clock_gettime
d5dd T clock_gettime
```
I modified ./configure to perform a more complicated test to handle
this case (see attached patch) but the build of the skaware programs
still fails because the -lrt sysdep is not added by default. Shouldn't
the deps-exe and deps-lib files of these programs be updated to add
${RT_LIB}?
BTW, I noticed that `s6-uevent-spawner` calls posix_spawnp() directly
instead of using child_spawn0().
So, for buildroot-s6, I ended up forcing -lrt in the runtime test
for posix_spawnp() in the ./configure script and passing LDLIBS=-lrt
to `make` when uclibc is selected [1].
[1]
https://github.com/elebihan/buildroot-s6/commit/98c9547fb3720859514b99d165aa80649a8a1ece
Best regards,
--
ELB
>From 9ad3c1032c3bac5f2e391c418324f26ee8abbe2d Mon Sep 17 00:00:00 2001
From: Eric Le Bihan
Date: Thu, 11 Aug 2016 19:57:09 +0200
Subject: [PATCH] configure: rework posix_spawn() detection
As uclibc-ng provides posix_spawn() in librt, rework the detection of
this function in the ./configure script to handle this situation.
---
configure | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index e4a1866..5320e41 100755
--- a/configure
+++ b/configure
@@ -450,6 +450,37 @@ EOF
echo ' ... no'
fi
+ echo "Checking whether system has posix_spawn()..."
+ hasposixspawn=true
+ if $CC_AUTO $CPPFLAGS_AUTO $CFLAGS_AUTO -c -o tryposixspawn.o src/sysdeps/tryposixspawn.c 2>/dev/null ; then
+if $CC_AUTO $CFLAGS_AUTO $LDFLAGS_AUTO -o /dev/null tryposixspawn.o 2>/dev/null ; then
+ rt_lib=
+ echo " ... yes"
+elif $CC_AUTO $CFLAGS_AUTO $LDFLAGS_AUTO -o /dev/null tryposixspawn.o -lrt 2>/dev/null ; then
+ rt_lib=-lrt
+ echo " ... yes, with -lrt"
+else
+ hasposixspawn=false
+fi
+rm -f tryposixspawn.o
+ else
+ hasposixspawn=false
+ fi
+ if $hasposixspawn ; then
+rm -f tryposixspawn
+if test "$rt_lib" = "-lrt" ; then
+ if ! grep -q "\-lrt" $sysdeps/rt.lib; then
+echo "-lrt" > $sysdeps/rt.lib
+ fi
+fi
+echo 'posixspawn: yes' >> $sysdeps/sysdeps
+echo "#define ${package_macro_name}_HASPOSIXSPAWN" >> $sysdeps/sysdeps.h
+ else
+echo 'posixspawn: no' >> $sysdeps/sysdeps
+echo "#undef ${package_macro_name}_HASPOSIXSPAWN" >> $sysdeps/sysdeps.h
+echo ' ... no'
+ fi
+
echo "Checking system endianness..."
$CC_AUTO $CPPFLAGS_AUTO $CFLAGS_AUTO -o tryendianness src/sysdeps/tryendianness.c
endianness=$(./tryendianness) || fail "$0: unable to determine endianness"
@@ -480,7 +511,6 @@ EOF
choose cl openat OPENAT 'openat()'
choose cl linkat LINKAT 'linkat()'
choose clr pipe2 PIPE2 'pipe2()'
- choose cl posixspawn POSIXSPAWN 'posix_spawn()' $rt_lib
choose clr ppoll PPOLL 'ppoll()'
choose cl revoke REVOKE 'revoke()'
choose cl sendfile SENDFILE 'sendfile()'
--
2.4.11
Re: skalibs: how to properly detect posix_spawnp() when using uclibc-ng?
Hi!
Le Fri, 12 Aug 2016 19:53:58 +0200,
Laurent Bercot a écrit :
> On 12/08/2016 12:23, Laurent Bercot wrote:
> > I need a more invasive patch. Going to work on it.
>
> That was painful.
> Eric: please test the current git versions of the whole skarnet.org
> stack (compatibility's broken with the previous versions, next
> release will have major version bumps) and tell me whether it works
> with uclibc-ng.
This looks good! I had to patch here and there for the static build to
work (see attached patches), but now it is possible to build
buildroot-s6 with uclibc-ng using the HEAD of the feature/uclibc branch
(commit 207c36f) [1].
The following configurations have been tested OK:
- demo_s6_uclibc_shared_qemu_x86_defconfig
- demo_s6_uclibc_static_qemu_x86_defconfig
I'll give a spin to demo_s6_uclibc_both_qemu_x86_defconfig later. I'll
do the same for the glibc/musl ones too, to see that nothing is broken.
Once the stable versions of skarnet programs and libraries will be
available, I'll respin the patch series I sent to upstream Buildroot.
Note that this series contains a patch for skalibs to check target
endianness using pre-processor directives instead of a runtime test. It
looks like the same can be used for size type check, so I'll work on
this too [2].
Thank you very much!
[1] https://github.com/elebihan/buildroot-s6/tree/feature/uclibc
[2] http://lists.busybox.net/pipermail/buildroot/2016-August/169456.html
--
ELB
>From 564e3178b135b4b24d0d1da5ac35ac9e35d9c489 Mon Sep 17 00:00:00 2001
From: Eric Le Bihan
Date: Tue, 16 Aug 2016 12:28:18 +0200
Subject: [PATCH] Fix spawn_lib dependency for s6-rc-init
Signed-off-by: Eric Le Bihan
---
package/deps.mak | 2 +-
src/s6-rc/deps-exe/s6-rc-init | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/deps.mak b/package/deps.mak
index 3e3938a..054d439 100644
--- a/package/deps.mak
+++ b/package/deps.mak
@@ -46,7 +46,7 @@ s6-rc-dryrun: EXTRA_LIBS := ${TAINNOW_LIB}
s6-rc-dryrun: src/s6-rc/s6-rc-dryrun.o -lskarnet
s6-rc-fdholder-filler: EXTRA_LIBS := ${TAINNOW_LIB} ${SOCKET_LIB}
s6-rc-fdholder-filler: src/s6-rc/s6-rc-fdholder-filler.o -ls6 -lskarnet
-s6-rc-init: EXTRA_LIBS := ${TAINNOW_LIB} ${SOCKET_LIB}
+s6-rc-init: EXTRA_LIBS := ${TAINNOW_LIB} ${SOCKET_LIB} ${SPAWN_LIB}
s6-rc-init: src/s6-rc/s6-rc-init.o ${LIBS6RC} -ls6 -lskarnet
s6-rc-oneshot-run: EXTRA_LIBS :=
s6-rc-oneshot-run: src/s6-rc/s6-rc-oneshot-run.o ${LIBS6RC} -lskarnet
diff --git a/src/s6-rc/deps-exe/s6-rc-init b/src/s6-rc/deps-exe/s6-rc-init
index b5622f9..5fb6d66 100644
--- a/src/s6-rc/deps-exe/s6-rc-init
+++ b/src/s6-rc/deps-exe/s6-rc-init
@@ -3,3 +3,4 @@ ${LIBS6RC}
-lskarnet
${TAINNOW_LIB}
${SOCKET_LIB}
+${SPAWN_LIB}
--
2.4.11
>From d56f2e2f79e7dcb9265373e97d2485bf40ab8d49 Mon Sep 17 00:00:00 2001
From: Eric Le Bihan
Date: Tue, 16 Aug 2016 10:24:51 +0200
Subject: [PATCH] Fix spawn_lib support
Signed-off-by: Eric Le Bihan
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index ab7279f..66a76f4 100755
--- a/configure
+++ b/configure
@@ -289,7 +289,7 @@ if [ "x$target" != "x$(cat $sysdeps/target)" ] ; then
exit 1
fi
-rt_lib=$(cat $sysdeps/rt.lib)
+spawn_lib=$(cat $sysdeps/spawn.lib)
socket_lib=$(cat $sysdeps/socket.lib)
sysclock_lib=$(cat $sysdeps/sysclock.lib)
tainnow_lib=$(cat $sysdeps/tainnow.lib)
@@ -365,7 +365,7 @@ sproot := $sproot
version := $version
home := $home
exthome := $exthome
-RT_LIB := ${rt_lib}
+SPAWN_LIB := ${spawn_lib}
SOCKET_LIB := ${socket_lib}
SYSCLOCK_LIB := ${sysclock_lib}
TAINNOW_LIB := ${tainnow_lib}
--
2.4.11
>From 9e4cdfedafb4fd73ab3674e9139d63a4ee0c8adb Mon Sep 17 00:00:00 2001
From: Eric Le Bihan
Date: Tue, 16 Aug 2016 12:24:28 +0200
Subject: [PATCH] Fix spawn_lib dependency for s6-svwait
Signed-off-by: Eric Le Bihan
---
package/deps.mak | 2 +-
src/supervision/deps-exe/s6-svwait | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/deps.mak b/package/deps.mak
index 7f77678..216f8cf 100644
--- a/package/deps.mak
+++ b/package/deps.mak
@@ -242,5 +242,5 @@ s6-svscanctl: EXTRA_LIBS :=
s6-svscanctl: src/supervision/s6-svscanctl.o ${LIBS6} -lskarnet
s6-svstat: EXTRA_LIBS := ${SYSCLOCK_LIB}
s6-svstat: src/supervision/s6-svstat.o ${LIBS6} -lskarnet
-s6-svwait: EXTRA_LIBS := ${SOCKET_LIB} ${TAINNOW_LIB}
+s6-svwait: EXTRA_LIBS := ${SOCKET_LIB} ${TAINNOW_LIB} ${SPAWN_LIB}
s6-svwait: src/supervision/s6-svwait.o src/supervision/s6_svlisten_loop.o ${LIBS6} -lskarnet
diff --git a/src/supervision/deps-exe/s6-svwait b/src/supervision/deps-exe/s6-svwait
index b71e12f..ab449ac 100644
--- a/src/supervision/deps-exe/s6-svwait
+++ b/src/supervision/deps-exe/s6-svwait
@@ -3,3 +3,4 @@ ${LIBS6}
-lskarnet
${SOCKET_LIB}
${TAINNOW_LIB}
+${SPAWN_LIB}
--
2.4.11
>From e09d1e79aacd5d8546eb8d85e28e844dd7aaff67 Mon Sep 17 00:0
Re: [announce] skarnet.org Spring 2017 release: s6 init fails with buildroot on MIPS
Hi! On 17-05-11 13:42:31, Van Bemten, Lionel (Nokia - BE/Antwerp) wrote: > Hello all, > > After upgrading to the below release of skarnet packages, my system > is not booting anymore on MIPS. I am using buildroot and the > s6-linux-init-skeleton > provided there by Éric Le Bihan. The master branch of upstream Buildroot currently contains the Fall 2016 skarnet release. I have not yet bumped to Spring 2017: as you may have seen, the patch for build time detection of types needs be refreshed. > The init usually stays blocked there: > > s6-rc: info: processing service fdholder: starting > > with the following processes running: > > 136 root s6-rc -v 3 -u change services-all > 143 root s6-fdholderd -1 -i data/rules > 146 root s6-ipcserverd -1 -- s6-ipcserver-access -v0 -E -l0 -i > data/rules -- s6-sudod -t 2000 -- /usr/libexec/s6-rc-oneshot-run -l > 173 root s6-svlisten1 -u -- /run/s6-rc/scandir/klogd-log s6-svc -u -- > /run/s6-rc/scandir/klogd-log > 183 root s6-ftrigrd > 296 root s6-svlisten1 -U -- /run/s6-rc/scandir/fdholder s6-svc -u -- > /run/s6-rc/scandir/fdholder > 297 root s6-ftrigrd > > and I regularly see the following message, even though not consistently: > > s6-ftrigrd: fatal: unable to flush asyncout: Broken pipe > > When I build the very same system for x86 I do not see any issue, it is very > stable, so I > suspect a cross-compilation issue. Since buildroot patches skalibs in order > to determine > system capabilities through build-time asserts instead of runtime tests, it > is possible that > something goes wrong there. However I have adapted the patches to the new > release, > and so far I cannot identify any error in the detected system settings. I do my cross-compilation tests using QEMU and I remember having this kind of issue sometimes. I always blamed it on a race condition and a slow QEMU emulation, without looking any futher. > If anyone has any idea to help the investigation, it would be highly > appreciated :). > Maybe for example a hint on what could cause s6-ftrigrd to get a broken pipe ? Would you care to share the Buildroot defconfig file you are using? Best regards, -- ELB
Re: [announce] skarnet.org Spring 2017 release: s6 init fails with buildroot on MIPS
Hi!
On 17-05-13 17:30:14, Laurent Bercot wrote:
> > > s6-ftrigrd: fatal: unable to flush asyncout: Broken pipe
> > I do my cross-compilation tests using QEMU and I remember having this
> > kind of issue sometimes. I always blamed it on a race condition and a
> > slow QEMU emulation, without looking any futher.
>
> s6-ftrigrd uses out-of-band message passing, which is badly specified,
> leaves a lot of leeway for implementations to get it wrong, and will
> only work when doing the exact right workarounds for the system you're
> using. So, getting the sysdeps right is especially important here.
>
> I know Buildroot cannot - for now, and I still hope this changes at
> some point - use predefined sysdeps, or run qemu'd autodetection tests,
> for cross-compilation. But you really do need to make sure that all your
> sysdeps are right.
Adding support for predefined sysdeps in Buildroot should be easy. The
problem is generating these predefined sysdeps for all the combinations
of architectures and libc supported by Buildroot.
Could all the cases be covered by using sysdeps generated with QEMU for
arm, aarch64, mips{32r2,64}{el,}, ppc{64,}{el,}, i386 in glibc,
uclibc-ng and musl flavors?
Running QEMU'd autodetection tests is a no-go, because it would require
building QEMU for Buildroot (which takes time). This kind of option has
already been rejected by upstream when discussing regeneration of
ld.so.cache using a cross-compiled ldconfig.
Best regards,
--
ELB
Re: SIGFPE in s6-rc-init 3.0.0 etc,...
On 17-12-15 00:59:12, Stefan Nilsson wrote: > Den 2017-12-14 kl. 23:44, skrev Eric Le Bihan: > > Hi all! > > > > On 17-12-14 22:35:52, Stefan Nilsson wrote: > > > Hey Laurent, > > > > > > > > So what to do,... I found: > > > https://skarnet.org/cgi-bin/archive.cgi?1:mss:1099:201711 > > > and decided to update to this version in my buildroot system instead, but > > > then I got a build error: > > > > > > make[1]: Entering directory > > > '/home/stefan/buildroot/output/build/s6-2.6.2.0' > > > exec /home/stefan/buildroot/output/host/bin/i586-buildroot-linux-gnu-gcc > > > -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -iquote src/include-local > > > -Isrc/include -Werror=implicit-function-declaration -Werror=implicit-int > > > -Werror=pointer-sign -Werror=pointer-arith > > > -I/home/stefan/buildroot/output/host/i586-buildroot-linux-gnu/sysroot/usr/include > > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe > > > -Wall > > > -std=c99 -fno-exceptions -fno-unwind-tables > > > -fno-asynchronous-unwind-tables > > > -Wa,--noexecstack -ffunction-sections -fdata-sections -O2 > > > -fomit-frame-pointer -fno-stack-protector -D_LARGEFILE_SOURCE > > > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -c -o > > > src/daemontools-extras/s6-applyuidgid.o > > > src/daemontools-extras/s6-applyuidgid.c > > > src/daemontools-extras/s6-applyuidgid.c: In function 'main': > > > src/daemontools-extras/s6-applyuidgid.c:57:29: error: implicit declaration > > > of function 'setgroups_and_gid' [-Werror=implicit-function-declaration] > > > if (gidn != (size_t)-1 && setgroups_and_gid(gid ? gid : getegid(), > > > gidn, > > > gids) < 0) > > > ^ > > > cc1: some warnings being treated as errors > > > > Being the submitter of the s6 patches to Buildroot, maybe I can help. > > > > IIUC, setgroups_and_gid() gets compiled only if SKALIBS_HASSETGROUPS is > > set in the file sysdeps.h generated by ./configure script. So maybe this > > file has been incorrectly generated for your platform. > > > > Could you share your Buildroot defconfig (or at least the toolchain > > specification) so I can test it on my side? > > Absolutely, you can find my buildroot defconfig here: > http://steffe.net/buildroot_defconfig > > Here is the patch I created to update the s6 packages: > http://steffe.net/0001-Updated-s6-packages.patch I posted a bump of these packages recently, which is similar to your patch. > So basically I had 2017.11 that built OK, applied the patch above, and got > the build error. Intriguing. I tested your defconfig and the build went like a charm using the HEAD of upstream Buildroot. The function setgroup() is properly detected by the configure script, which compiles and links a test program using the cross-compiler: ``` + choose cl setgroups SETGROUPS setgroups() + what=cl + name=setgroups + macro=SETGROUPS + echo Checking whether system has setgroups()... + IFS= + printf %s\n Checking whether system has setgroups()... Checking whether system has setgroups()... + shift 4 + libs= + r=true + /home/eric/build/test-s6/x86/host/bin/i586-buildroot-linux-gnu-gcc -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -Isrc/include -Werror=implicit-function-declaration -Werror=implicit-int -Werror=pointer-sign -Werror=pointer-arith -Wno-unused-value -Wno-parentheses -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Wall -std=c99 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -ffunction-sections -fdata-sections -O2 -fomit-frame-pointer -fno-stack-protector -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -o trysetgroups.o -c src/sysdeps/trysetgroups.c + true + /home/eric/build/test-s6/x86/host/bin/i586-buildroot-linux-gnu-gcc -pipe -Wall -std=c99 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -ffunction-sections -fdata-sections -O2 -fomit-frame-pointer -fno-stack-protector -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -Wl,--sort-section=alignment -Wl,--sort-common -Wl,--hash-style=both -o trysetgroups trysetgroups.o + true + rm -f trysetgroups.o trysetgroups + true + echo setgroups: yes + IFS= + printf %s\n setgroups: yes + echo #define SKALIBS_HASSETGROUPS + IFS= + printf %s\n #define SKALIBS_HASSETGROUPS ``` The previous trace has been generated by using "sh -x ./configure" in skalibs.mk. Check how this goes in your case and have a look at the generated sysdeps.h. > Btw, do you know when we
skalibs: issue with strnlen() when statically linking with uclibc-ng
Hi!
The autobuilder system of the Buildroot project (which rebuilds packages
for multiple architectures and toolchains) reported an issue when
building s6-rc 0.0.4.0 for ARM using uclibc-ng statically [1]. The build
ends as follows:
```
/accts/mlweber1/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(strnlen.os):
In function `strnlen':
strnlen.c:(.text+0x0): multiple definition of `strnlen'
/accts/mlweber1/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/skalibs/libskarnet.a(strnlen.o):strnlen.c:(.text.strnlen+0x0):
first defined here
```
It means that skalibs v2.6.3.0 has been compiled with its internal variant of
strnlen(), as the configuration script failed to detect the one provided by
uclibc-ng.
When trying to recreate the build issue, using a tweaked version of
skalibs/configure gives us more information:
```
/home/eric/build/test-s6-rc-0.0.4.0-arm/host/bin/arm-linux-gcc
-D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -Isrc/include
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=pointer-sign
-Werror=pointer-arith -Wno-unused-value -Wno-parentheses -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Wall -std=c99
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables
-Wa,--noexecstack -ffunction-sections -fdata-sections -O2 -fomit-frame-pointer
-fno-stack-protector -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os -static -o trystrnlen.o -c src/sysdeps/trystrnlen.c
src/sysdeps/trystrnlen.c: In function 'main':
src/sysdeps/trystrnlen.c:10:10: error: implicit declaration of function
'strnlen' [-Werror=implicit-function-declaration]
return strnlen("/", 1) ;
^~~
cc1: some warnings being treated as errors
```
The MAN page for strnlen() from glibc states that _POSIX_C_SOURCE should be
defined and uclibc-ng seems to behave the same. The _POSIX_C_SOURCE is indeed
passed by Buildroot to the cross-compiler when build the program.
But since v2.6.3.0, skalibs/src/sysdeps/trystrnlen.c clears the definition of
_POSIX_C_SOURCE. Allowing it again solves the issue: the uclibc-ng version of
strnlen() is detected, skalibs internal variant is disabled and s6-rc-update
statically links with uclibc-ng like a charm.
I tried to statically link with musl and surprisingly, there is no linking error
even though the skalibs variant of strnlen() is enabled and musl provides it
too!
```
$ grep STRNLEN
~/build/demo-s6/qemu/x86/musl/static/staging/usr/include/skalibs/sysdeps.h
#undef SKALIBS_HASSTRNLEN
$ grep STRNLEN
~/build/demo-s6/qemu/x86/uclibc/static/staging/usr/include/skalibs/sysdeps.h
#undef SKALIBS_HASSTRNLEN
```
One of the differences between uclibc-ng and musl is that uclibc-ng, as glibc,
defines strnlen() using libc_hidden_def(strnlen), which results in the following
when inspecting symbols:
```
$ objdump -t ~/build/demo-s6/qemu/x86/musl/static/staging/lib/libc.a | grep
strnlen
*UND* strnlen
[...]
*UND* strnlen
strnlen.o: format de fichier elf32-i386
ldf *ABS* strnlen.c
ld .text.strnlen .text.strnlen
g F .text.strnlen 0033 strnlen
*UND* strnlen
$ objdump -t ~/build/demo-s6/qemu/x86/uclibc/static/staging/usr/lib/libc.a |
grep strnlen
*UND* __GI_strnlen
*UND* __GI_strnlen
strnlen.os: format de fichier elf32-i386
ldf *ABS* strnlen.c
ld .text.__GI_strnlen .text.__GI_strnlen
g F .text.__GI_strnlen 0034 .hidden __GI_strnlen
g F .text.__GI_strnlen 0034 strnlen
*UND* __GI_strnlen
```
Would this difference explains why there is no redefinition linking error with
musl, or am I missing something?
What is the reason for clearing _POSIX_C_SOURCE from trystrnlen.c?
[1]
http://autobuild.buildroot.net/results/59f3b6d5fe3e9b561adbafc08eeb1a23f7100278/
Regards,
--
ELB
Re: skalibs: issue with strnlen() when statically linking with uclibc-ng
On 2018-01-13 21:09, Laurent Bercot wrote: > > > What is the reason for clearing _POSIX_C_SOURCE from trystrnlen.c? > > The set of functions made visible by a libc is generally bigger when > you do *not* define any POSIX or XOPEN macro: systems don't feel like > they have to respect a particular namespace, and export all they have, > or close to all they have. _POSIX_C_SOURCE usually means "only declare > what is strictly POSIX, and if the application is trying to use an > extension, it's an error". > > This is true even for functions actually defined by POSIX, such as > futimens(), the openat() family of functions, and the whole > sys/socket.h family of functions; some (arguably old) libcs mistakenly > fail to expose them when POSIX macros are defined, but expose them > when no such macro is defined. Sometimes they also require a specific > extension macro to expose them. The biggest culprits of this are > Solaris, MacOS, and NetBSD. The only libcs I've never seen stray from > POSIX visibility rules are glibc and musl. > > And so, when testing a function's existence, I usually remove all > POSIX macro definitions, assuming that the visibility will be higher > and the function has a higher chance of being detected - so the > system's function is used instead of the workaround. > > In the case of strnlen, though, it appears that this assumption is > wrong. I just tested without the undefs, and unless I missed something > again, strnlen is correctly detected on all the systems that have it. > > My bad then, it's a bug. The latest git head performs the trystrnlen.c > test without the undefs; please test it. If it works for you, I'll > release a new version of skalibs with the fix. Thanks for the detailed explanation. I tested the latest git head and the problem is solved. Thank you! Regards, -- ELB
