Samuel Thibault wrote:
> ORIGIN support was only commited in 2018-01-08
The commit
<https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=311ba8dc4416467947eff2ab327854f124226309>
introduced a new symbol '_hurd_exec_paths' in glibc. But when I write
an autoconf test that tests for this symbol, it fails.
Reduced test case:
$ cat foo.c
char _hurd_exec_paths ();
int
main ()
{
return _hurd_exec_paths ();
}
$ gcc -Wall foo.c
/usr/bin/ld: /tmp/ccwyTc0R.o: in function `main':
foo.c:(.text+0x14): undefined reference to `_hurd_exec_paths'
collect2: error: ld returned 1 exit status
$ nm --dynamic /lib/i386-gnu/libc.so.0.3 | grep hurd_exec
00025b60 T _hurd_exec
00025b80 T _hurd_exec_file_name
00022e10 T _hurd_exec_paths
$ nm --dynamic --with-symbol-versions /lib/i386-gnu/libc.so.0.3 | grep hurd_exec
00025b60 T _hurd_exec@@GLIBC_2.2.6
00025b80 T _hurd_exec_file_name@@GLIBC_2.21
00022e10 T _hurd_exec_paths@GLIBC_2.26
The symbol version is not GLIBC_INTERNAL; then why is the symbol not accessible?
And '_hurd_exec' is accessible, but gives a deprecation warning
"_hurd_exec is deprecated, use _hurd_exec_paths instead". What sense does it
make that an accessible symbol is deprecated in favour of a symbol that is not
accessible?
Bruno
