bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/22962] [RISCV] add abi subdirectories support to ld


From: belyshev at depni dot sinp.msu.ru
Subject: [Bug ld/22962] [RISCV] add abi subdirectories support to ld
Date: Wed, 14 Mar 2018 22:57:18 +0000

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.


reply via email to

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