Re: ld and rpath in .so

[Andrew Bell <andrew dot bell dot ia at gmail dot com>]

I'm answering this myself for anyone who might stumble upon it.  See below.

On Wed, Jan 23, 2019 at 9:25 PM Andrew Bell <andrew.bell.ia@gmail.com>
wrote:

>
> On Wed, Jan 23, 2019 at 8:20 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
>> On 1/23/19 7:58 PM, Andrew Bell wrote:
>> > I have learned that the conda toolchain is built as a cross-toolchain,
>> > which I believe explains ld ignoring rpath for secondary dependencies.
>>
>> A cross-toolchain should not ignore rpath, but it may be setup to honour
>> a sysroot prefix which is pre-pended to the rpath.
>>
>> > Thanks for reading.
>> >
>> > On Wed, Jan 23, 2019, 5:38 PM Andrew Bell <andrew.bell.ia@gmail.com
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> My understanding is that ld will use the RPATH in a shared object to
>> >> locate secondary shared objects when linking an executable.
>>
>> Which link? Static link or dynamic link?
>>
>> At static link time it's the value of -Wl,-rpath or -Wl,-rpath-link.
>>
>> At dynamic link  time it's the value of DT_RPATH in the dyanmic section.
>>
>
> Now I'm confused.  I'm talking static link.  The issue is ld making sure
> all the symbols are defined when building an executable.  Perhaps this
> simple example helps:
>
> ====== so_secondary.cpp
>
> int secondary()
> {
>         return 25;
> }
>
> ====== so_primary.cpp
> int secondary();
>
> int primary()
> {
>         return secondary();
> }
>
> ====== executable.cpp
> #include <iostream>
>
> int primary();
>
> int main()
> {
>         std::cerr << "Value = " << primary() << "!\n";
> }
>
> ======
> $ g++ -fPIC -shared so_secondary.cpp -o so_secondary.so
> $ g++ -fPIC -shared so_primary.cpp -o so_primary.so
> -Wl,-rpath=/home/acbell/c++link  so_secondary.so
> $ g++ executable.cpp -o executable so_primary.so
>
> This works fine on a native system.  When executable is linked, the symbol
> in so_secondary.so is found.
>
> If instead I build so_primary without the rpath, I get an error that I
> expect (still on a native system):
>
> $ g++ -fPIC -shared so_secondary.cpp -o so_secondary.so
> $ g++ -fPIC -shared so_primary.cpp -o so_primary.so so_secondary.so
> $ g++ executable.cpp -o executable so_primary.so
> /usr/bin/ld: warning: so_secondary.so, needed by so_primary.so, not found
> (try using -rpath or -rpath-link)
> so_primary.so: undefined reference to `secondary()'
> collect2: error: ld returned 1 exit status
>
> This can be resolved by adding -rpath or -rpath-link when building
> executable.
>
> However, on the conda (crosstool) system, I get the error shown above even
> if the rpath is built into so_primary.so  Only using -rpath-link when
> building executable seems to allow so_secondary.so be found and the link of
> executable to complete without the warning/error shown above.
>
> >> I'm trying to build a conda package and this doesn't seem to be
>> >> happening.  I can use readelf to verify that the RPATH is set in the
>> linked
>> >> library to point to the directory containing the secondary libraries,
>> but
>> >> when I link my executable with the linked library, I get an error
>> saying
>> >> that the secondary libraries can't be found.  Using -rpath-link on the
>> >> command line to explicitly specify the path that's embedded in the
>> linked
>> >> library rpath resolves the issue (though -rpath on the command line
>> >> fails).  I'm using ld through g++ 7.3.
>>
>> You have this backward. Using -rpath embeds the path via DT_RPATH, but
>> using -rpath-link does not.
>>
>
> I understand this.  I guess I was not clear.
>
>
>> Searching -rpath for a cross-linker *requires* --with-sysroot.
>>
>
It turns out that a recent change to ld added the sysroot to rpath entries
when searching for libraries:

https://sourceware.org/ml/binutils/2017-03/msg00134.html

So, rpaths are searched, but not with the path as one might expect.

How do I check the cross linker's --with-sysroot option?
>

Use the --print-sysroot option.
-- 
Andrew Bell
andrew.bell.ia@gmail.com