This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |