GCC fails when SDK is not extracted to /usr/local

GCC fails when SDK is not extracted to /usr/local

[Tasslehoff Kjappfot]

gcc fails when I extract my SDK to another place than /usr/local.

Output when it fails:

$ ./arm-angstrom-linux-gnueabi-gcc
bash: ./arm-angstrom-linux-gnueabi-gcc: No such file or directory

Readelf output:

$ readelf -d arm-angstrom-linux-gnueabi-gcc

Dynamic section at offset 0x34394 contains 21 entries:
   Tag        Type                         Name/Value
  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
  0x0000000f (RPATH)                      Library rpath: 
[/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/usr/lib/armv7a-angstrom-linux-gnueabi:/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/lib]

Is it the RPATH here that's making trouble for me?

- Tasslehoff

Re: GCC fails when SDK is not extracted to /usr/local

[Tom Rini]

On Wed, Dec 7, 2011 at 12:16 AM, Tasslehoff Kjappfot
<tasskjapp@gmail.com> wrote:
> gcc fails when I extract my SDK to another place than /usr/local.
>
> Output when it fails:
>
> $ ./arm-angstrom-linux-gnueabi-gcc
> bash: ./arm-angstrom-linux-gnueabi-gcc: No such file or directory
>
> Readelf output:
>
> $ readelf -d arm-angstrom-linux-gnueabi-gcc
>
> Dynamic section at offset 0x34394 contains 21 entries:
>  Tag        Type                         Name/Value
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>  0x0000000f (RPATH)                      Library rpath:
> [/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/usr/lib/armv7a-angstrom-linux-gnueabi:/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/lib]
>
> Is it the RPATH here that's making trouble for me?

Not exactly.  And RPATH is needed to find some of the shared libraries
that are needed.  I thought we had been running chrpath over these to
make them relocatable, however.

-- 
Tom

Re: GCC fails when SDK is not extracted to /usr/local

[Tasslehoff Kjappfot]

On Dec 8, 2011, at 3:56 PM, Tom Rini wrote:

> On Wed, Dec 7, 2011 at 12:16 AM, Tasslehoff Kjappfot
> <tasskjapp@gmail.com> wrote:
>> gcc fails when I extract my SDK to another place than /usr/local.
>> 
>> Output when it fails:
>> 
>> $ ./arm-angstrom-linux-gnueabi-gcc
>> bash: ./arm-angstrom-linux-gnueabi-gcc: No such file or directory
>> 
>> Readelf output:
>> 
>> $ readelf -d arm-angstrom-linux-gnueabi-gcc
>> 
>> Dynamic section at offset 0x34394 contains 21 entries:
>>  Tag        Type                         Name/Value
>>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>>  0x0000000f (RPATH)                      Library rpath:
>> [/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/usr/lib/armv7a-angstrom-linux-gnueabi:/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/lib]
>> 
>> Is it the RPATH here that's making trouble for me?
> 
> Not exactly.  And RPATH is needed to find some of the shared libraries
> that are needed.  I thought we had been running chrpath over these to
> make them relocatable, however.
> 
> -- 
> Tom
> 

Does this RPATH indicate that its not relocatable? Anything else I can check?

- Tasslehoff

Re: GCC fails when SDK is not extracted to /usr/local

[Mark Hatle]

On 12/8/11 1:04 PM, Tasslehoff Kjappfot wrote:
>
> On Dec 8, 2011, at 3:56 PM, Tom Rini wrote:
>
>> On Wed, Dec 7, 2011 at 12:16 AM, Tasslehoff Kjappfot
>> <tasskjapp@gmail.com>  wrote:
>>> gcc fails when I extract my SDK to another place than /usr/local.
>>>
>>> Output when it fails:
>>>
>>> $ ./arm-angstrom-linux-gnueabi-gcc
>>> bash: ./arm-angstrom-linux-gnueabi-gcc: No such file or directory
>>>
>>> Readelf output:
>>>
>>> $ readelf -d arm-angstrom-linux-gnueabi-gcc
>>>
>>> Dynamic section at offset 0x34394 contains 21 entries:
>>>   Tag        Type                         Name/Value
>>>   0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>>>   0x0000000f (RPATH)                      Library rpath:
>>> [/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/usr/lib/armv7a-angstrom-linux-gnueabi:/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/lib]
>>>
>>> Is it the RPATH here that's making trouble for me?
>>
>> Not exactly.  And RPATH is needed to find some of the shared libraries
>> that are needed.  I thought we had been running chrpath over these to
>> make them relocatable, however.
>>
>> --
>> Tom
>>
>
> Does this RPATH indicate that its not relocatable? Anything else I can check?

It should be using RUN_PATH  $ORIGIN to relocate itself based on the initial 
run-time location.

It sounds like something is not being run as it should for the SDK component(s).

--Mark

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

Re: GCC fails when SDK is not extracted to /usr/local

[Khem Raj]

On Thu, Dec 8, 2011 at 11:11 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 12/8/11 1:04 PM, Tasslehoff Kjappfot wrote:
>>
>>
>> On Dec 8, 2011, at 3:56 PM, Tom Rini wrote:
>>
>>> On Wed, Dec 7, 2011 at 12:16 AM, Tasslehoff Kjappfot
>>> <tasskjapp@gmail.com>  wrote:
>>>>
>>>> gcc fails when I extract my SDK to another place than /usr/local.
>>>>
>>>> Output when it fails:
>>>>
>>>> $ ./arm-angstrom-linux-gnueabi-gcc
>>>> bash: ./arm-angstrom-linux-gnueabi-gcc: No such file or directory
>>>>
>>>> Readelf output:
>>>>
>>>> $ readelf -d arm-angstrom-linux-gnueabi-gcc
>>>>
>>>> Dynamic section at offset 0x34394 contains 21 entries:
>>>>  Tag        Type                         Name/Value
>>>>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>>>>  0x0000000f (RPATH)                      Library rpath:
>>>>
>>>> [/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/usr/lib/armv7a-angstrom-linux-gnueabi:/usr/local/angstrom-eglibc-i686-armv7a/sysroots/i686-angstromsdk-linux/lib]
>>>>
>>>> Is it the RPATH here that's making trouble for me?
>>>
>>>
>>> Not exactly.  And RPATH is needed to find some of the shared libraries
>>> that are needed.  I thought we had been running chrpath over these to
>>> make them relocatable, however.
>>>
>>> --
>>> Tom
>>>
>>
>> Does this RPATH indicate that its not relocatable? Anything else I can
>> check?
>
>
> It should be using RUN_PATH  $ORIGIN to relocate itself based on the initial
> run-time location.
>
> It sounds like something is not being run as it should for the SDK
> component(s).

it should come by inheriting relocatable class I think and this class is being
inherited in cross|native|nativesdk classes.