non-standard library locations and rpath

non-standard library locations and rpath

[Jack Mitchell]

I'm having some troubles with shared library, shared library 
dependencies and rpaths. I have libfoo, which depends on libbar when I 
try to link libfoo with my app, it requires libbar to be found. libbar 
is in a non-standard location, /usr/local/bar when I compiled libfoo, I 
used -Wl,rpath-link ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath 
/usr/local/bar. Now when I come to try link my app with libfoo, it fails 
to link as it can't find libbar, which I assume means the rpath in 
libfoo isn't being properly prepending with sysroot what is the proper 
way to support this in OE? My library has the following rpath information:

0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I compile 
my app and link libfoo? The apps build system is using cmake, but this 
should be a built in linker feature, correct?

Cheers,
Jack.

Re: non-standard library locations and rpath

[Khem Raj]

On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
> I'm having some troubles with shared library, shared library dependencies
> and rpaths. I have libfoo, which depends on libbar when I try to link libfoo
> with my app, it requires libbar to be found. libbar is in a non-standard
> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now when I
> come to try link my app with libfoo, it fails to link as it can't find
> libbar, which I assume means the rpath in libfoo isn't being properly
> prepending with sysroot what is the proper way to support this in OE? My
> library has the following rpath information:
>
> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>
> So why isn't the rpath being prepended with the sysroot when I compile my
> app and link libfoo? The apps build system is using cmake, but this should
> be a built in linker feature, correct?

Only first path ( before :) is relative to location of binary at runtime

>
> Cheers,
> Jack.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: non-standard library locations and rpath

[Jack Mitchell]

On 02/12/16 07:08, Khem Raj wrote:
> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>> I'm having some troubles with shared library, shared library dependencies
>> and rpaths. I have libfoo, which depends on libbar when I try to link libfoo
>> with my app, it requires libbar to be found. libbar is in a non-standard
>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now when I
>> come to try link my app with libfoo, it fails to link as it can't find
>> libbar, which I assume means the rpath in libfoo isn't being properly
>> prepending with sysroot what is the proper way to support this in OE? My
>> library has the following rpath information:
>>
>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>
>> So why isn't the rpath being prepended with the sysroot when I compile my
>> app and link libfoo? The apps build system is using cmake, but this should
>> be a built in linker feature, correct?
>
> Only first path ( before :) is relative to location of binary at runtime
>

Exactly, so how can you make an OE build use the rpaths of libs that 
point to the build sysroot. What I have at the moment is

0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE 
sees the rpath in it's cross compile environment it should prepend it 
with the build sysroot so you end up with something like

0x0000000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

And then the SDK should end up with something like

0x0000000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

Is this what is expected to happen, or am I stumbling into an 
unsupported scenario.

Cheers,

Re: non-standard library locations and rpath

[Jack Mitchell]

On 05/12/16 10:44, Jack Mitchell wrote:
> On 02/12/16 07:08, Khem Raj wrote:
>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>> I'm having some troubles with shared library, shared library
>>> dependencies
>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>> libfoo
>>> with my app, it requires libbar to be found. libbar is in a non-standard
>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>> when I
>>> come to try link my app with libfoo, it fails to link as it can't find
>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>> prepending with sysroot what is the proper way to support this in OE? My
>>> library has the following rpath information:
>>>
>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>
>>> So why isn't the rpath being prepended with the sysroot when I
>>> compile my
>>> app and link libfoo? The apps build system is using cmake, but this
>>> should
>>> be a built in linker feature, correct?
>>
>> Only first path ( before :) is relative to location of binary at runtime
>>
>
> Exactly, so how can you make an OE build use the rpaths of libs that
> point to the build sysroot. What I have at the moment is
>
> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>
> Which would be correct if I was linking on the target. However when OE
> sees the rpath in it's cross compile environment it should prepend it
> with the build sysroot so you end up with something like
>
> 0x0000000f (RPATH) Library rpath:
> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>
> And then the SDK should end up with something like
>
> 0x0000000f (RPATH) Library rpath:
> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>
> Is this what is expected to happen, or am I stumbling into an
> unsupported scenario.
>
> Cheers,

I think basically what I'm saying is that does the linker prepend it's 
--sysroot value to absolute rpaths, and if not, should it?

Re: non-standard library locations and rpath

[Khem Raj]

On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>
>
> On 05/12/16 10:44, Jack Mitchell wrote:
>>
>> On 02/12/16 07:08, Khem Raj wrote:
>>>
>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>>
>>>> I'm having some troubles with shared library, shared library
>>>> dependencies
>>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>>> libfoo
>>>> with my app, it requires libbar to be found. libbar is in a non-standard
>>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>>> when I
>>>> come to try link my app with libfoo, it fails to link as it can't find
>>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>>> prepending with sysroot what is the proper way to support this in OE? My
>>>> library has the following rpath information:
>>>>
>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>
>>>> So why isn't the rpath being prepended with the sysroot when I
>>>> compile my
>>>> app and link libfoo? The apps build system is using cmake, but this
>>>> should
>>>> be a built in linker feature, correct?
>>>
>>>
>>> Only first path ( before :) is relative to location of binary at runtime
>>>
>>
>> Exactly, so how can you make an OE build use the rpaths of libs that
>> point to the build sysroot. What I have at the moment is
>>
>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>
>> Which would be correct if I was linking on the target. However when OE
>> sees the rpath in it's cross compile environment it should prepend it
>> with the build sysroot so you end up with something like
>>
>> 0x0000000f (RPATH) Library rpath:
>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>
>> And then the SDK should end up with something like
>>
>> 0x0000000f (RPATH) Library rpath:
>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>
>> Is this what is expected to happen, or am I stumbling into an
>> unsupported scenario.
>>
>> Cheers,
>
>
> I think basically what I'm saying is that does the linker prepend it's
> --sysroot value to absolute rpaths, and if not, should it?

having absolute build paths into rpaths is not a good thing. Linker
will search the libs during link in sysroot its configured to do so.

>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: non-standard library locations and rpath

[Jack Mitchell]

On 05/12/16 16:43, Khem Raj wrote:
> On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>
>>
>> On 05/12/16 10:44, Jack Mitchell wrote:
>>>
>>> On 02/12/16 07:08, Khem Raj wrote:
>>>>
>>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>>>
>>>>> I'm having some troubles with shared library, shared library
>>>>> dependencies
>>>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>>>> libfoo
>>>>> with my app, it requires libbar to be found. libbar is in a non-standard
>>>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>>>> when I
>>>>> come to try link my app with libfoo, it fails to link as it can't find
>>>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>>>> prepending with sysroot what is the proper way to support this in OE? My
>>>>> library has the following rpath information:
>>>>>
>>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>>
>>>>> So why isn't the rpath being prepended with the sysroot when I
>>>>> compile my
>>>>> app and link libfoo? The apps build system is using cmake, but this
>>>>> should
>>>>> be a built in linker feature, correct?
>>>>
>>>>
>>>> Only first path ( before :) is relative to location of binary at runtime
>>>>
>>>
>>> Exactly, so how can you make an OE build use the rpaths of libs that
>>> point to the build sysroot. What I have at the moment is
>>>
>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>
>>> Which would be correct if I was linking on the target. However when OE
>>> sees the rpath in it's cross compile environment it should prepend it
>>> with the build sysroot so you end up with something like
>>>
>>> 0x0000000f (RPATH) Library rpath:
>>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>>
>>> And then the SDK should end up with something like
>>>
>>> 0x0000000f (RPATH) Library rpath:
>>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>>
>>> Is this what is expected to happen, or am I stumbling into an
>>> unsupported scenario.
>>>
>>> Cheers,
>>
>>
>> I think basically what I'm saying is that does the linker prepend it's
>> --sysroot value to absolute rpaths, and if not, should it?
>
> having absolute build paths into rpaths is not a good thing. Linker
> will search the libs during link in sysroot its configured to do so.
>

Ok, that makes sense. So something like this would be more appropriate?

rel_path = relative_path(mylib, otherlib)

-Wl,-rpath $ORIGIN${relpath}

Re: non-standard library locations and rpath

[Khem Raj]

On Mon, Dec 5, 2016 at 9:41 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>
>
> On 05/12/16 16:43, Khem Raj wrote:
>>
>> On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>
>>>
>>>
>>> On 05/12/16 10:44, Jack Mitchell wrote:
>>>>
>>>>
>>>> On 02/12/16 07:08, Khem Raj wrote:
>>>>>
>>>>>
>>>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell <ml@embed.me.uk> wrote:
>>>>>>
>>>>>>
>>>>>> I'm having some troubles with shared library, shared library
>>>>>> dependencies
>>>>>> and rpaths. I have libfoo, which depends on libbar when I try to link
>>>>>> libfoo
>>>>>> with my app, it requires libbar to be found. libbar is in a
>>>>>> non-standard
>>>>>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>>>>>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>>>>>> when I
>>>>>> come to try link my app with libfoo, it fails to link as it can't find
>>>>>> libbar, which I assume means the rpath in libfoo isn't being properly
>>>>>> prepending with sysroot what is the proper way to support this in OE?
>>>>>> My
>>>>>> library has the following rpath information:
>>>>>>
>>>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>>>
>>>>>> So why isn't the rpath being prepended with the sysroot when I
>>>>>> compile my
>>>>>> app and link libfoo? The apps build system is using cmake, but this
>>>>>> should
>>>>>> be a built in linker feature, correct?
>>>>>
>>>>>
>>>>>
>>>>> Only first path ( before :) is relative to location of binary at
>>>>> runtime
>>>>>
>>>>
>>>> Exactly, so how can you make an OE build use the rpaths of libs that
>>>> point to the build sysroot. What I have at the moment is
>>>>
>>>> 0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>>>
>>>> Which would be correct if I was linking on the target. However when OE
>>>> sees the rpath in it's cross compile environment it should prepend it
>>>> with the build sysroot so you end up with something like
>>>>
>>>> 0x0000000f (RPATH) Library rpath:
>>>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>>>
>>>> And then the SDK should end up with something like
>>>>
>>>> 0x0000000f (RPATH) Library rpath:
>>>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>>>
>>>> Is this what is expected to happen, or am I stumbling into an
>>>> unsupported scenario.
>>>>
>>>> Cheers,
>>>
>>>
>>>
>>> I think basically what I'm saying is that does the linker prepend it's
>>> --sysroot value to absolute rpaths, and if not, should it?
>>
>>
>> having absolute build paths into rpaths is not a good thing. Linker
>> will search the libs during link in sysroot its configured to do so.
>>
>
> Ok, that makes sense. So something like this would be more appropriate?
>
> rel_path = relative_path(mylib, otherlib)
>
> -Wl,-rpath $ORIGIN${relpath}

This could work.

>
>
>