[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[sbergman at redhat dot com]

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.