[Bug binutils/20177] New: ld ignores --with-lib-path and -L for indirectly loaded libraries

[romain.geissler at amadeus dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20177

            Bug ID: 20177
           Summary: ld ignores --with-lib-path and -L for indirectly
                    loaded libraries
           Product: binutils
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I am wondering what is the expected behavior of ld when a library is implicitly
loaded. What should be the behavior of the linker when:
 - libA.so depends on libB.so (there is a DT_NEEDED entry for libB.so in
libA.so)
 - I link main.o against libA.so, but because my Makefile is wrongly written I
forget to link it against libB.so as well
?

Currently it looks like ld tries to open and link against libB.so even if it
doesn't explicitly appear on the command line. But it appears that ld is
completely ignoring the configure-time option --with-lib-path, as well as all
the -L/path/to/lib that gcc passes to the linker, and looks for libraries in
/lib64 instead. As a result, if I link against a library that requires pthread
without the "-pthread" or "-lpthread" flag, then ld ends up trying to link
against /lib64/libpthread.so.0 rather than
/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib/libpthread.so.0 that I would expect
since I used at configure time
--with-lib-path=/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib. I have a custom GNU
toolchain (gcc, binutils, glibc) correctly bootstrapped with the correct
--prefix installed in /opt/1A/toolchain/x86_64-2.6.32-v3-0. This toolchain is
using a glibc that is more recent than the system one (installed in /li64).
Since there is a glibc mismatch, when using the system's libpthread.so rather
than the custom one, I end up with link errors.

Here is how I reproduce it:
##### Makefile #####
export PATH:=/opt/1A/toolchain/x86_64-2.6.32-v3/bin:${PATH}
LDFLAGS+=-Wl,-v

all:test

libA.so:CFLAGS=-fPIC
libA.so:LDFLAGS:=${LDFLAGS} -shared -pthread
libA.so:libA.c
        $(LINK.c) $< $(LOADLIBES) $(LDLIBS) -o $@

test:LDFLAGS:=${LDFLAGS} -L. -lA
# Uncomment the following to have a proper configuration
#test:LDFLAGS:=${LDFLAGS} -pthread
test:test.c libA.so
        $(LINK.c) $< $(LOADLIBES) $(LDLIBS) -o $@

clean:
        ${RM} libA.so test

.PHONY:all clean

##### libA.c #####
#include <errno.h>

int f()
{
    return errno;
}

##### test.c #####
int main() {}


Notice the error of configuration in the makefile where "test" is not built
with -pthread while in theory it should.

When I build this, I end up with:
cc -fPIC  -Wl,-v -shared -pthread  libA.c   -o libA.so  
collect2 version 6.1.1 20160511  
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/bin/ld
-plugin
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/liblto_plugin.so
-plugin-opt=/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/lto-wrapper
-plugin-opt=-fresolution=/gctmp/rgeissler/ccVWxeIP.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared -z relro
--enable-new-dtags -o libA.so
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crti.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtbeginS.o
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib/../lib64
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/lib
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../..
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib -v /gctmp/rgeissler/ccdS9FX6.o -lgcc
--as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtendS.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crtn.o
 
GNU ld (GNU Binutils) 2.26.0.20160511
cc   -Wl,-v -L. -lA  test.c   -o test 
collect2 version 6.1.1 20160511
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/bin/ld
-plugin
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/liblto_plugin.so
-plugin-opt=/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/lto-wrapper
-plugin-opt=-fresolution=/gctmp/rgeissler/ccbl0ijW.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m
elf_x86_64 -dynamic-linker
/opt/1A/toolchain/x86_64-2.6.32-v3/lib/ld-linux-x86-64.so.2 -z relro
--enable-new-dtags -o test
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crt1.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crti.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtbegin.o
-L.
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib/../lib64
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/lib
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../..
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib -v -lA /gctmp/rgeissler/ccEqHmod.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtend.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crtn.o
 
GNU ld (GNU Binutils) 2.26.0.20160511
/lib64/libpthread.so.0: undefined reference to address@hidden'
/lib64/libpthread.so.0: undefined reference to
address@hidden'
collect2: error: ld returned 1 exit status
make: *** [test] Error 1

So it looks like ld is looking for libraries in /lib64 no matter how it was
configured. Using -L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib or setting
LIBRARY_PATH=/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib doesn't change anything.
Is this really what we would expect from ld ? For me ld should either:
 - explicitly warn me that I didn't use "-lpthread" while I really should
 - or silently ignore the fact that I forgot "-lpthread", but then use libs
specified in --with-lib-dir a configure time + the libs specified with -L flags
rather than the hardcoded default /lib64 or /lib.

Note: I am using binutils 2.26.
Note 2: this is the same kind of problem which caused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021

Cheers,
Romain

-- 
You are receiving this mail because:
You are on the CC list for the bug.