External toolchains

External toolchains

[Luke (Lucas) Starrett]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Hi,

For various reasons, we have a need to work with pre-compiled external toolchains, in this case, the 2014-09 Linaro aarch64 release.  A key difference between this specific toolchain vs. the Fido/1.8 out of the box toolchain (4.9.2 + patches?), is that the Linaro version is built with --enable-multiarch.  We end up with applications built with search paths such as /lib/aarch64, /usr/lib/aarch64, etc,  but libraries installed in the normal /lib, /usr/lib paths.  Obviously if we use the built-in toolchain recipes in 1.8, life is good, search paths match install paths.

I wanted to understand a couple points.


1)      What are the long term goals/roadmap are in this area specific to Yocto/OE?

2)      Where is the "right" place to deal with this?

a.       Configure (based on detected toolchain capability)

b.      Install (override library destination?)

c.       Other?

3)      Any other examples that can be used as a reference?

I've seen a few emails in the archives that seem to touch on this, but none that really seemed to come to any conclusion.

Thanks,

Luke Starrett

[-- Attachment #2: Type: text/html, Size: 6797 bytes --]

Re: External toolchains

[Nikolay Dimitrov]

Hi Luke,

On 07/07/2015 08:35 PM, Luke (Lucas) Starrett wrote:
> Hi,
>
> For various reasons, we have a need to work with pre-compiled external
> toolchains, in this case, the 2014-09 Linaro aarch64 release.  A key
> difference between this specific toolchain vs. the Fido/1.8 out of the
> box toolchain (4.9.2 + patches?), is that the Linaro version is built
> with --enable-multiarch.  We end up with applications built with search
> paths such as /lib/aarch64, /usr/lib/aarch64, etc,  but libraries
> installed in the normal /lib, /usr/lib paths.  Obviously if we use the
> built-in toolchain recipes in 1.8, life is good, search paths match
> install paths.
>
> I wanted to understand a couple points.
>
> 1)What are the long term goals/roadmap are in this area specific to
> Yocto/OE?
>
> 2)Where is the “right” place to deal with this?
>
> a.Configure (based on detected toolchain capability)
>
> b.Install (override library destination?)
>
> c.Other?

Is it possible for you to use ld.so.conf to point to the proper library
paths?

> 3)Any other examples that can be used as a reference?
>
>
> I’ve seen a few emails in the archives that seem to touch on this, but
> none that really seemed to come to any conclusion.
>
> Thanks,
>
> Luke Starrett

Regards,
Nikolay

Re: External toolchains

[Luke (Lucas) Starrett]

Nikolay,

While that might work, it seems like this is more an issue of installation in the improper place.  I was hoping there surely there would be someone who is using the stock Linaro aarch64 toolchains and had tackled this issue.

Thanks, Luke.


-----Original Message-----
From: Nikolay Dimitrov [mailto:picmaster@mail.bg] 
Sent: Tuesday, July 07, 2015 3:19 PM
To: Luke (Lucas) Starrett; yocto@yoctoproject.org
Subject: Re: [yocto] External toolchains

Hi Luke,

On 07/07/2015 08:35 PM, Luke (Lucas) Starrett wrote:
> Hi,
>
> For various reasons, we have a need to work with pre-compiled external 
> toolchains, in this case, the 2014-09 Linaro aarch64 release.  A key 
> difference between this specific toolchain vs. the Fido/1.8 out of the 
> box toolchain (4.9.2 + patches?), is that the Linaro version is built 
> with --enable-multiarch.  We end up with applications built with 
> search paths such as /lib/aarch64, /usr/lib/aarch64, etc,  but 
> libraries installed in the normal /lib, /usr/lib paths.  Obviously if 
> we use the built-in toolchain recipes in 1.8, life is good, search 
> paths match install paths.
>
> I wanted to understand a couple points.
>
> 1)What are the long term goals/roadmap are in this area specific to 
> Yocto/OE?
>
> 2)Where is the "right" place to deal with this?
>
> a.Configure (based on detected toolchain capability)
>
> b.Install (override library destination?)
>
> c.Other?

Is it possible for you to use ld.so.conf to point to the proper library paths?

> 3)Any other examples that can be used as a reference?
>
>
> I've seen a few emails in the archives that seem to touch on this, but 
> none that really seemed to come to any conclusion.
>
> Thanks,
>
> Luke Starrett

Regards,
Nikolay

Re: External toolchains

[Khem Raj]

On Tue, Jul 7, 2015 at 10:35 AM, Luke (Lucas) Starrett
<lstarret@broadcom.com> wrote:
> Hi,
>
>
>
> For various reasons, we have a need to work with pre-compiled external
> toolchains, in this case, the 2014-09 Linaro aarch64 release.  A key
> difference between this specific toolchain vs. the Fido/1.8 out of the box
> toolchain (4.9.2 + patches?), is that the Linaro version is built with
> --enable-multiarch.  We end up with applications built with search paths
> such as /lib/aarch64, /usr/lib/aarch64, etc,  but libraries installed in the
> normal /lib, /usr/lib paths.  Obviously if we use the built-in toolchain
> recipes in 1.8, life is good, search paths match install paths.
>
>
>
> I wanted to understand a couple points.
>
>
>
> 1)      What are the long term goals/roadmap are in this area specific to
> Yocto/OE?

OE provides provisions to hook in external toolchain thats where it
ends. Its a moving target since the specifics of internal toolchain
and metadata
change all the time, so external toolchain recipe has to constantly modify.

>
> 2)      Where is the “right” place to deal with this?

external toolchain providers they need to keep it in sync

>
> a.       Configure (based on detected toolchain capability)



>
> b.      Install (override library destination?)
>
> c.       Other?
>
> 3)      Any other examples that can be used as a reference?
>
>
> I’ve seen a few emails in the archives that seem to touch on this, but none
> that really seemed to come to any conclusion.


there is external-sourcery-toolchain recipe that you can use as
template, but since people generate toolchains
with different infrastructures and options its simply not a
supportable model, it never ends and cant be defined.