Re: False positive in skalibs system feature test

From: Guillermo <>
Date: Thu, 24 Oct 2019 01:04:17 -0300

El mié., 23 oct. 2019 a las 6:50, Laurent Bercot escribió:
> >/usr/bin/ld: src/librandom/random_string.lo: in function `random_string':
> >./src/librandom/random_string.c:26: warning: getrandom is not
> >implemented and will always fail
> [...]
> >ld returns zero, even it knows "xxx is not implemented and will always fail".
> That, on the other hand, is completely insane. Why the heck isn't it
> an error? It's *precisely* the kind of thing I want ld to error out on!
> [...]
> >I only observe such case on GNU Hurd/K*BSD actually. I'm thinking if
> >only these non-linux systems have such confused behaviour(why it links
> >successfully at all...)
> That would be interesting to explore, yes.

I also think that this is a GNU libc thing. As far as I can tell, it
contains a 'stub' getrandom() that does nothing, returns -1, and sets
errno to ENOSYS, unless it is built for an OS that can provide a
'real' getrandom():


In the upstream libc package, this seems to happen only for Linux,
where it is just a wrapper around the corresponding system call:


I would think that for 'pure' GNU (Hurd) and GNU/k*BSD there is no
'real' getrandom() implementation, so the libc gets the 'stub' one,
although the kernel of FreeBSD 12.0, has a getrandom() system call
that the libc could use.


That "stub_warning()" macro turns out to be a GCC trick to display the
"is not implemented and will always fail" message: if an ELF object
file contains .gnu.warning.<symbol> section, GNU ld knows what it
means, shows a warning, removes the section in the resulting file, and
returns 0, because an excecutable is still produced, although with an
implementation of getrandom() that is not useful for skalibs :P Here's
an example of the trick:

$ cat libtest.c
#include <errno.h>
#include <stdio.h>

int test_function() {
   fprintf (stderr, "test_function(): I told you! I don't work!\n");
   return errno = ENOSYS, -1;

//Magic, create a .gnu.warning.test_function ELF section
static char message[] __attribute__ ((used,
   = "libtest: I provide a \"test_function\" symbol, but I don't
actually implement the function";

$ gcc -shared -Wl, -o -fPIC -DPIC libtest.c
$ objdump -h | grep .gnu.warning
 23 .gnu.warning.test_function 00000059 0000000000000000
0000000000000000 00003060 2**5

$ cat test-program.c
#include <errno.h>
#include <stdio.h>
#include <string.h>

int test_function();

int main() {
   if (test_function()) fprintf (stderr, "test-program: ERROR: %s\n",

$ gcc -o test-program -Wl,-rpath=/home/guillermo -L. test-program.c -ltest
/usr/bin/ld: /tmp/ccu3uP4m.o: in function `main':
test-program.c:(.text+0xa): warning: libtest: I provide a
"test_function" symbol, but I don't actually implement the function

$ objdump -h test-program | grep .gnu.warning
$ ./test-program
test_function(): I told you! I don't work!
test-program: ERROR: Function not implemented

So, it seems that,:for the purposes of detecting whether there is a
usable getrandom(),for skallibs:

* If GNU libc is used, a 'choose cl' test is unreliable.
* GNU/Hurd and GNU/k*BSD would be 'getrandom: no' OSes, at least until
the libc is updated to make a system call on GNU/kFreeBSD [1]
* A 'choose clr' test would be reliable.
* Any other alternative (passing an LDFLAGS that produces a build
failure, overriding the result of tests, or whatever) kind of implies
knowledge about what the outcome of the detection is going to be,
anyway, doesn't it? It's not really a detection.

[1] Is Debian the upstream of the libc port to GNU/kFreeBSD?

Received on Thu Oct 24 2019 - 04:04:17 UTC

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