https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #2 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> ---
(In reply to Jim Wilson from comment #1)
> It isn't clear what bug you are trying to report here, or what glibc change
> you are referring to. Some info on how to reproduce would be useful.
The bug can be reproduced on a native system with upstream glibc from 2.27
branch (release does not work because of dynamic linker cache bug).
script to reproduce:
echo 'void f1(){}' > f1.c
echo 'void f1(); int main() { f1(); }' > f2.c
gcc f1.c -shared -fPIC -lm -o f1.so
gcc f2.c -o f2 f1.so
output:
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/../../../../riscv64-unknown-linux-gnu/bin/ld:
warning: libm.so.6, needed by f1.so, not found (try using -rpath or
-rpath-link)
The testcase was extracted from build failure of an "expect" package.
This happens because since upstream glibc submission v3
(https://www.sourceware.org/ml/libc-alpha/2017-12/msg00912.html) all libraries
for a selected abi variant placed under a subdirectory of /lib*:
/lib*/<abi-variant>/. E.g. for RV64 with lp64d they are installed in
/lib64/lp64d and /usr/lib64/lp64d.
So with unmodified ld the lp64d abi subdirectory is omitted from SEARCH_PATH,
as is apparent when using -Wl,--verbose:
$ gcc f2.c -o f2 f1.so -Wl,--verbose
...
<snipped>
...
SEARCH_DIR("/usr/riscv64-unknown-linux-gnu/lib64");
SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64");
SEARCH_DIR("/usr/riscv64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib");
SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
...
> If we do need multilibbed native compilers, then we may have a problem with
> directory names, as we don't have any convention for this as yet. At the
> moment, the only convention we have is that 64-bit code is in /lib64 and
> 32-bit code is in /lib.
As per above, this no longer appears to be the case and the default library
placement has changed to /lib*/<abi>/
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
