|
Kevin Schaffer(deleted)
|
rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/08/2015 4:44 PM
post112882
|
rpath or rpath-link doesn't resolve downstream .so needs?
I'm linking an executable that links against a .so. The .so has a function in it that's in another .so.
The link for the original executable chokes at this point, saying that it can't find the secondary .so, needed by the
primary one, needed by the executable.
It then immediately chokes, saying "undefined reference to xxx", where xxx is the function in the secondary .so, needed
by the primary .so, needed by the executable. (This function is not, by the way, needed by the executable, just by the
.so it needs.)
I tried adding -rpath-link to it, and put the full path from C root all the way to the secondary .so's folder (being
careful to swap \ for / .)
I still get the exact same error, including not being able to find the secondary .so.
Objdump shows the primary .so knows it needs the secondary .so, but (does not know where to look at runtime??? How
would I check that? I use -x for objdump and see the "NEEDED" line for it, no runtime path info, so I assumed it was
just in the shared library path.) Or is it embedded, and I need a different objdump argument to add or to look in a
different part of the output of objdump? Is this runtime path, if it exists, where the linker is trying to find the
secondary .so, so it ignores rpath-link?
So:
1. Does -rpath-link not apply to "downstream" .so's? What would I use in its place?
Assume for the sake of argument the (linktime path on the development machine) is not the same as the runtime path on
the target device, which it is not.
The linker must find the .so at link time to verify the function it needs is, in fact, inside the .so, right? So why
does it ignore -rpath-link=c:/(somePathWithoutSpaces)/mySoLibDir ?
|
|
|
|
|
|
Kevin Schaffer(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/08/2015 5:15 PM
post112884
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
Ok, I tried
-Wl,-Bdynamic -lsecondaryLibrary
and
-rpath-link=(pathWithoutSpacesToDevelopmentMachineLocationOfThatSO)
and...cannot find -lsecondaryLibrary
How can it not find it? I gave it the path via -rpath-link.
From the -rpath-link description:
-rpath-link=dir
When using ELF or SunOS, one shared library may require another. This happens when an "ld -shared" link includes a
shared library as one of the input files.
When the linker encounters such a dependency when doing a non-shared, non-relocatable link, it will automatically try to
locate the required shared library and include it in the link, if it is not included explicitly. <-------------------
-------------
So how could I "include it explicitely"?
Assume:
Executable
primary.so
secondary.so
where secondary.so contains function x(), which primary.so needs, but Executable does not (directly.)
Assume primary.so is in a path the linker finds when you specify Bdynamic -lprimary.
Assume secondary.so is in some funky directory, say, c:\a\b\c
Would I want to use -lsecondary? Or could I just provide a path to secondary.so, including the name "secondary.so"?
(Cries) alls I wants to do is tell the linker here's the danged .so, here's where it is, and you will need this because
it contains x(), which primary.so needs.
|
|
|
|
|
|
Kevin Schaffer(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/08/2015 5:40 PM
post112885
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
Ok, this is just precioius.
I copied secondary.so into the same directory as primary.so, and this is the only spot in the entire build tree where
either exist, AND IT STILL CANNOT FIND secondary.so.
I've dragged ld, kicking and screaming, into a single room, sawn open its eyeballs, sunk a mechanical claw into the back
of its skull, and used a 30-ton robot arm to twist it's head to point its horrified face directly at secondary.so, and
it still lies to me that it cannot see it.
|
|
|
|
|
|
Jeff Baker
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Jeff Baker
01/09/2015 9:03 AM
post112891
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
As an experiment, if you add the secondary .so to the link line directly as an input file, does that resolve the issue?
|
|
|
|
|
|
Kevin Schaffer(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/09/2015 10:20 AM
post112893
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
Ok, I added a path to it after the -o (primary link file.o) ../whatever/secondary.so, and it worked fine.
This is a one-off for testing, but it may need to get integrated in the future, so setting it up as a library in a (new)
library path is the eventual goal.
|
|
|
|
|
|
Ryan Mansfield(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Ryan Mansfield(deleted)
01/09/2015 9:08 AM
post112892
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
On 15-01-08 05:15 PM, Kevin Schaffer wrote:
> Ok, I tried
> -Wl,-Bdynamic -lsecondaryLibrary
>
> and
> -rpath-link=(pathWithoutSpacesToDevelopmentMachineLocationOfThatSO)
>
> and...cannot find -lsecondaryLibrary
>
>
> How can it not find it? I gave it the path via -rpath-link.
If it's a dependency of your library and not your original executable,
then you shouldn't be explicitly linking against it by specifying
-lsecondaryLibrary.
-lsecondaryLibrary should be specified when you link libfirstlibrary,
but not a.out. If you specify -lsecondaryLibrary, ld will be looking for
it in the library search path (i.e directories specified by -L).
Regards,
Ryan Mansfield
|
|
|
|
|
|
Kevin Schaffer(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/09/2015 10:21 AM
post112894
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
This is a new .so from a 3rd party, so I would like to put it in a new folder. Then I would have to add this folder's
path to the (development machine) search path, and then I could use -lsecondary?
|
|
|
|
|
|
Elena Laskavaia
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Elena Laskavaia
01/23/2015 9:06 AM
post113063
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
You have to add path by adding -L<path> option to linker or adding
library to directory which is already on the path (pre-existing -L's or
one standard dirs in $QNX_TARGET)
On 15-01-09 10:21 AM, Kevin Schaffer wrote:
> This is a new .so from a 3rd party, so I would like to put it in a new folder. Then I would have to add this folder's
path to the (development machine) search path, and then I could use -lsecondary?
>
>
>
> _______________________________________________
>
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post112894
> To cancel your subscription to this discussion, please e-mail momentics-community-unsubscribe@community.qnx.com
|
|
|
|
|
|
Kevin Schaffer(deleted)
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
|
|
Kevin Schaffer(deleted)
01/23/2015 11:14 AM
post113065
|
Re: rpath or rpath-link doesn't resolve downstream .so needs?
Thank you, I did exactly that!
|
|
|
|
|
|
