Should ld consider -rpath '$ORIGIN' when finding dependencies?

[Jonathan Wakely]

Consider this case (reproducable with the attached Makefile)

echo 'int bar();   int main() { return bar(); }' > main.c
echo 'int foo();   int bar() { return foo(); }' > bar.c
echo 'int i;   int foo() { return i; }' > foo.c
cc -shared -Wl,-h,libfoo.so -fPIC foo.c -L. '-Wl,-rpath,$ORIGIN'  -o libfoo.so
cc -shared -Wl,-h,libbar.so -fPIC bar.c -L. '-Wl,-rpath,$ORIGIN' -lfoo
-o libbar.so
cc main.c -L. '-Wl,-rpath,$ORIGIN' -lbar -o main
/usr/bin/ld: warning: libfoo.so, needed by ./libbar.so, not found (try
using -rpath or -rpath-link)
./libbar.so: undefined reference to `foo'
collect2: error: ld returned 1 exit status
make: *** [main] Error 1

libbar.so depends on libfoo.so, so when linking main to libbar.so the
linker checks for libfoo.so, but fails.

If I replace '-Wl,-rpath,$ORIGIN' with -Wl,-rpath,$PWD it works (using
the attached Makefile that can be done with "make RPATH=$PWD") but
that puts the wrong RPATH in the executable.

If I add -Wl,-rpath-link,. it works.

If I use Gold it works.

So is this a ld bug, or just a difference between bfd and gold?

I expected this to work given that ./libbar.so contains
DT_RPATH=$ORIGIN and ./main is being given DT_RPATH=$ORIGIN too, both
of which would allow finding ./libfoo.so at runtime, so I expect it to
link successfully.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 415 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20130502/6f4babda/attachment.obj>