Re: ld and rpath in .so

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

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.
>

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

Thanks,

-- 
Andrew Bell
andrew.bell.ia@gmail.com