https://sourceware.org/bugzilla/show_bug.cgi?id=20535
--- Comment #2 from Stephan Bergmann <sbergman at redhat dot com> --- (In reply to Nick Clifton from comment #1) > The problem here is that you are using environment variables which are not > being expanded at link time. No, I'm not using environment variables. I'm rather using the $ORIGIN token supported by ld.so's rpath token expansion (see "man ld.so"). > > $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos > > -ldso1 > > This stores a DT_NEEDED string of "$ORIGIN" into libdso2.so. It does > *not* > store the expansion of $ORIGIN into the DT_NEEDED entry. I assume you mean DT_RPATH instead of DT_NEEDED? And that this creates a DT_RPATH of exactly "$ORIGIN" is expected. > > $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2 > > This makes the linker look in a directory path called "$ORIGIN/dsos", again > with no expansion of $ORIGIN, which is why this approach also fails. (Note > this behaviour is intended. The linker does not perform expansion of > environment variables found in path names). But when ld.so supports $ORIGIN (and some more special tokens) in DT_RPATH, wouldn't it be useful if ld did, too? (I just notice that I failed to add "-z origin" when using "-Wl,-rpath='$ORIGIN...", but even adding that to the two affected gcc invocations doesn't make a difference.) > This sequence does work: > > % setenv ORIGIN `pwd` > % mkdir dsos > % gcc -shared -fPIC -o dsos/libdso1.so dso1.c > % gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath=$ORIGIN/dsos dso2.c > -Ldsos -ldso1 That causes an absolute path be recorded into dso2's DT_RPATH, which is /not/ what is wanted. > % gcc main.c -Ldsos -ldso2 -- 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