Re: Relocatable toolchain

[Filipp Andjelo <Filipp dot Andjelo at tomtom dot com>]

Hello Yann, hello *,

On 18.06.2013 00:36, Yann E. MORIN wrote:
> Filipp, All,
>
> On 2013-06-17 14:40 +0000, Filipp Andjelo spake thusly:
>> Hi,
>>
>> I built a toolchain using crosstool-ng and it works fine, as far as I
>> don't move it to another folder. I want to have a toolchain, which I can
>> put everywhere, but how?
> As Thomas already pointed out, the toolchains built by crosstool-NG
> *are* relocatable (well, should be, otherwise this is a bug, but so far
> I never encountered such a condition).
>
>> If I run "gcc --print-sysroot", I get absolute path to the directory,
>> where toolchain was built.
> This is expected.
>
> The sysroot handling in gcc is a bit tricky (I don't really know the
> exact gory details, but here are an excerpt based on experience):
>    - gcc first tries to see if it's configured sysroot exists
>      - if so, uses it
>    - if not, then gcc tries to see if it is running from the location
>      it's been configured for
>    - if not, gcc apllies to its configured sysroot the same change, and
>      uses the new path for the surrent sysroot
>
> For example, let's say gcc was configured with:
>      --prefix=/opt/toolchain
>      --sysroot=/opt/toolchain/tuple/sysroot
>
> But you then moved the toolchain:
>      /opt/toolchain    -->   /some/place/new/base
>
> gcc will see the relocation; then it constructs a relative path to the
> sysroot from its configuration:
>      /opt/toolchain/tuple/sysroot
>      ^^^^^^^^^^^^^^  <- this is gcc's --prefix, so it gets removed.
>
>      /tuple/sysroot    <- this is the relative path to the sysroot.
>
> And gcc now adds its new location in front:
>      /some/place/new/base/tuple/sysroot
>
> Note-1: if the sysroot is not a sub-path of the prefix, this will not
> work, and the toolchain will not be relocatable. That's why crosstool-NG
> insists on not letting the user specify the path to the sysroot in the
> menuconfig, and computes it itself.
>
> Note-2: there can be a case where the toolchain has been relocated, but
> the original sysroot already exists (eg. another toolchain was built
> with the same prefix). In this case, you'd get in much trouble!
> Especially if the sysroot of the new toolchain is read-only, you'd get
> weird build errors later on, or if it is read-write, you'd get either
> weirder build errors, or worse, run-time errors.. Well, I said sysroot
> path computation by gcc was tricky, didn't I? ;-)
>
>> If I check the same for google's Android
>> toolchain, I get relative path
>> to the gcc. How did they do that?
> I don't know why/how Android's toolchains are built thus, but we can't
> do it for crosstool-NG (long story made short: canadian builds).
>
>> Currently, I have a workaround using CFLAGS="--sysroot=path/to/sysroot",
>> but It's not acceptable solution here.
> No, and this is wrong. The toolchain should be relocatable. Can you
> share the .config that produces this non-relocatable toolchain, please?
>
> Regards,
> Yann E. MORIN.
>

thank you very much for the detailed explanation, it's very informative! 
As I said, I rebuilt the toolchain using similar sample configuration 
and that worked as expected. Then I tried to find the important 
difference, but didn't find anything. So I took my config again and made 
completely clean trial. And now it works as expected..... I can't 
explain that, nor I can reproduce the state.... I hate magic :)

If I get it reproduced one day and/or get more info about it, I'll write 
again. Nevertheless, thanks a lot for your help!

Cheers,
Filipp