https://sourceware.org/bugzilla/show_bug.cgi?id=31904
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Herman,
It is all in a name ...
The problem is that there is a libg.a in the standard library search paths
and this is being picked up instead of your local libg.a. (Because the libdep
plugin adds the new library search path to the end of the list of places to
search).
To see this, try adding the -Wl,--verbose option to the final cc command
line. In my tests I get output like this:
[...]
attempt to open f/libg.so failed
attempt to open f/libg.a failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/13/libg.so failed
attempt to open /usr/lib/gcc/x86_64-redhat-linux/13/libg.a failed
attempt to open /usr/lib64/libg.so failed
attempt to open /usr/lib64/libg.a succeeded
[...]
ld: f/libf.a(f.o): in function `f':
<stdin>:(.text+0xa): undefined reference to `g'
If you change the name of your library to, say, libgg.a and adjust the makefile
accordingly then it all works:
[...]
got deps for library f/libf.a:
-Ltests/g -lgg
[...]
attempt to open /usr/lib64/libgg.a failed
[...]
attempt to open tests/g/libgg.a succeeded
[...]
Now I expect that you are going to say that the bfd linker ought to insert
search paths derived from the libdep plugin *before* other search paths. But I
would argue that this is a serious security risk. Searching for libraries in
non-standard locations is a bad idea, especially for system libraries. So, if
anything, I would say that the real problem is that the gold linker did not
fail this test...
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
