Re: native toolchain build

[Michael Zintakis <michael dot zintakis at googlemail dot com>]

Yann,


Thanks for this detailed response. Further comments below:
> > What I just did is configure my toolchain as "cross", but having the 
> > same architecture as the build/host/target machine (x86_64 in my case).
> >
> > It all goes well,
> >     
>
> I am not sure that will make a working native toolchain. Sure, it will
> most probably be able to compile and link code, but what about runtime?
> I hope you are right, but:
> - when you ./configure programs, do they find libs only in the sysroot,
>   or do they search in /lib and /usr/lib ? If the former, good, but the
>   latter is an error (potentially not the same ABI).
>   
Good question - I don't know that yet because I've had this weird *.la 
problem (see the thread I started called "[BUG?]" etc) to deal with and 
still can't get it sorted, which is very annoying. I did try to compile 
and run a couple of simple (hello-world like) program for basic checks, 
but beyond that I haven't done any proper testing yet.

Logic dictates that because I "forced" ct-ng to do "cross" compilation 
(with its separate sysroot directory) then all the files present there 
will be searched for and linked in the same way as they are with 
"proper" cross toolchain. At least that is the case with my true cross 
toolchain, which I can vouch for that it works well. So, I am hopeful!

The native toolchain (N.B. not cross-native!) in my case will be used to 
compile and build basic programs (like the bash shell, sed, awk, perl 
and the like) which in turn will be used when I, at a later stage, enter 
the chroot environment to build & install the rest of the software on 
the built machine (x86_64, hence these programs need to be x86_64-based, 
i.e. native).

Additional software will be compiled using my already-built cross 
toolchain. That native toolchain will *not* be used again once I enter 
chroot - it's sole purpose is simply to ensure "pure" code is built - 
"from scratch" so to speak - and this code will then assist in the 
chroot environment to install the rest of the software. As I am going to 
chroot using my build machine environment (x86_64) I only need to build 
the tools for that platform, though this needs to be done in "pure" form 
(without using the gcc, libraries etc - in other words, the toolchain 
already existing on the build machine) - apart from compiling the 
"native" gcc and its toolchain of course.

So, to clarify, I need to have this (arrows - "->" - means "built by"):

Toolchain0 -> Toolchain1 -> Toolchain2 -> Toolchain3

Toolchain0 (x86_64->x86_64) - the toolchain already present on the build 
machine. This, to me, is not pure as it may be "polluted" by 
distro-specific "peculiarities", so I can't really rely on it apart from 
building a "native" toolchain (see Toolchain1 below).

Toolchain1 (x86_64->x86_64) - this toolchain which is also native (to 
the build machine), but is built from scratch and independent from 
anything else present on the build machine to ensure the code is in 
"pure" form. This is what I am struggling with at present, hence the 
start of this thread.

Toolchain2 (x86_64->i3/4/5/686 or powerpc (G2-G5)) - my cross toolchain 
- this is already built and works as expected (in fact, I am so far very 
pleased with what I've got out of it!). To make things simple I am 
currently only experimenting with the i686 branch to iron things out 
first before switching to ppc.

Toolchain3 (i3/4/5/686 or powerpc (G2-G5)->i3/4/5/686 or powerpc 
(G2-G5)) - "cross-native" - this is "partially" built in a sense that I 
have used the libraries present in the Toolchain2's sysroot directory 
and then built GCC on top of it. Tested it (albeit not thoroughly) and 
it works. The main purpose will be to be able to compile and run code 
for the target arch on the target arch only!

> - where do you install your programs: /, /usr, /usr/local, other place?
>   
~/distrib/tools/native{/, /usr}, bearing in mind that when I later on 
chroot it will be chroot to ~/distrib. It is also worth noting that when 
I did build the whole thing I've specifically created a symlink called 
"/tools" (i.e. directory called "tools" on my real root of the build 
system) pointing to ~/distrib/tools and all prefixes of that toolchain 
reference "/tools" (as in the symlink) - this will aide me later on when 
I enter the chroot environment as that prefix won't change!

> - where are they looking for, and finding their libraries in, at runtime?
>   
Pass! I don't know yet, but will check this, though as I pointed out 
above I am hopeful that they point to the right places. Will let you know.

> In fact, as the toolchain is made of different components than your build
> system (which is also host and target!), you *may* end up with a different
> ABI, or even a different API (you can configure out stuff from eglibc or
> uClibc, which make them expose a different ABI and/or API).
>
> So you do not want programs and libs you build with this toolchain to use
> any lib from your host system, at all.
>   
Very true and this is why I have this long-winded Toolchain0-Toolchain3 
scenario - to avoid exactly that sort of thing. When the programs from 
Toolchain1 and Toolchain2 are built they are completely separate - 
Toolchain1 is residing in /tools/native, Toolchain2 is residing in 
/tools/cross and each have their own sysroot directories - while the 
final software will be built in a yet another separate - empty - 
directory called /distrib/buildroot. Complete separation is absolutely 
necessary, very true!

> In fact, I am not even sure what a 'native' toolchain should be. There are
> a few definitions that match the idea of 'native' toolchain:
>
>  1) replace the existing toolchain
>   
This!

>  2) work side-by-side with the existing toolchain
>  3) create a toolchain that runs on a _new_ system,
>
> Obviously, 3) above if in fact a cross-native toolchain, even if the
> build, host and target systems are the same. It's just that it won't
> run on the *exact* system that it was built on, just the same ARCH/CPU,
> but in a different environment. So it's a cross-native.
>   
No, it isn't, as cross-native is host=target, which, in my case at 
least, is very different. It is "native-native" as build=target.

> The easiest solution might be 2), but it means we have to teak the paths
> in the dynamic linker (ld.so) so that it does not look in the usual places,
> but in the sysroot of the toolchain, and install all programs compiled with
> this toolchain in the sysroot. But that is not really convenient.
>   
That's not an option for me as I will be polluting the toolchain with 
distro-specific peculiarities and that means introducing an unstable 
factor in the whole process. My (extended) plan is to build Toolchain1, 
which is then properly tested (and passes these tests!), which is then 
used to do the everything else. Yes, I know I could skip it, but as I 
already pointed out - I will be introducing potentially unstable/unknown 
element into the whole process and I simply cannot afford to do that.

> An alternative solution would be to build a non-sysrooted toolchain, and
> have the sysroot to be /opt and use /opt as a --prefix for all programs
> that are built with this toolchain. And stil we'd have to tweak the
> dynamic linker to look in /opt/lib instead of the usual places (and use
> /opt/etc/ld.so.conf, and so on...)
>   
That is the first thing I tried, but failed - miserably so! I spent a 
good couple of hours on this, but couldn't get out of it and opted to 
"cheat" and build a "cross" toolchain which has exactly the same arch as 
the build machine. You've made a good point to check which libraries are 
referenced and I will be doing just that in the coming days.

> As for 1), I think it is really complex. It means that you will have to
> live with two (or more!) C libraries side-by-side, one for the old programs
> linked against the original C library/ies, the second your new C library.
> And 2+ dynamic linkers as well; and so on...
It is not that complex if you think about it - I can "cut" all the links 
from the "old" native/present toolchain (Toolchain0 in my scenario 
above) and force it to use my own native libraries. It is not very 
different from using a proper cross toolchain if you think about it - 
all you have to do is readjust the path and, as in the case when I have 
a cross toolchain, all libraries should/would be referenced/present in 
the sysroot directory.

The only difference would be that, as it happens, this "cross" toolchain 
has the same arch as the build system - why should it be any different?

The only difficulty I have is that I need to force the use of <tuple>-*, 
which I wasn't sure I could easily correct if I 1) readjust my path to 
"/tools/native/bin:$PATH"; and 2) rename all <tuple>-* to just * (where 
* is ar, strip, gcc, ld, etc), which is why I started this thread.

>  I do not think this is doable.
>   
I will have some more time at the beginning of next week and would be 
able to test this more thoroughly, though I wanted to first canvas some 
opinion from the more knowledgeable on this list first, before I plunge 
myself and start digging deep.

> > but I end up with a bunch of executables like  
> > "<x86_64-tuple>-*" (* being gcc, ar, ranlib, strip etc). Is it safe to 
> > rename these to their "natural" name - without the tuple (or at least 
> > symlink them) - or is this going to cause me problems when using these 
> > executables?
> >     
>
> In case you want to achieve 2) above, then you should not just rename them,
> as you do want (yes, I know you do! ;-) ) to differentiate the original
> compiler for your build system, that is called 'gcc', from the new compiler.
>   
Once Toolchain1 is built (and properly tested) I don't (shouldn't!) 
really use the existing toolchain - that is the whole purpose of the 
exercise. Once I build my software image though, I just either archive 
or wipe out the whole ~/distrib directory and restore the original paths 
etc and everything should be back to normal again. I won't be needing 
this any more...

> Integration into crosstool-NG: yes!
> Planed: no.
> Any time soon: probably not.
>
> In fact, I would rather wish that thwe abovequestions be answered before
> adding new code. Then we can start adding that support. Maybe it's just
> a matter of a few lines of code and some switches here and there, but I
> doubt it.
>   
The way I see it, the native toolchain is a subset of the cross 
toolchain (at least in my case!) where the target=build, so, in my view 
it should not be treated any differently. If you choose to go that path, 
the only possible difference in the code you need to do is to remove the 
target arch/cpu and proceed from there (all ./configure parameters will 
be with --build=<build_tuple> --host=<build_tuple> and 
--target=<build_tuple>), except that at the end there needs to be a 
rename of the binaries in the bin directory (there are also "proper" 
binaries in the sysroot/bin directory, which I am not sure what they are 
for or whether they are the same - if so, it makes sense to use them 
instead!).

Obviously, that would work if the proper libraries are referenced and 
not the ones from Toolchain0 - you raised a good point about them and 
I'll check this at first opportunity early next week.

> I am even thinking that purely 'native' toolchains is a non-issue, and
> that cross-native would solve the issue. Is there really a need to install
> and use a _second_ _native_ toolchain on an existing system?
Yes, there is! The main reason is because this toolchain would be, 
presumably, free from distro-specific stuff, it is built from source and 
could be tested properly - that is the main advantage as far as I can 
see, otherwise there are so many different distros out there and each 
one has its peculiarities in it.

By building a native toolchain from scratch (provided it is done 
properly) all these problems go away in an instant!


Lastly, Yann, congratulations on your new domain - you will be rubbing 
shoulders with the big guys now, be proud!

MZ

--
For unsubscribe information see http://sourceware.org/lists.html#faq