[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $ORIGIN substitution in RPATH

From: Bruno Haible
Subject: Re: $ORIGIN substitution in RPATH
Date: Sat, 23 Feb 2019 21:12:53 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

Samuel Thibault wrote:
> ORIGIN support was only commited in 2018-01-08

The commit
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 ();

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]