Re: native toolchain build

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Michael, All,

On Saturday 09 April 2011 11:04:20 Michael Zintakis wrote:
> I've just realised that the above is yet to be implemented in cr-ng (the 
> menuconfig says "NO CODE").

Indeed. It is not supported for now, it's just a place holder.

> 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).
- where do you install your programs: /, /usr, /usr/local, other place?
- where are they looking for, and finding their libraries in, at runtime?

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.


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
 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.

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.

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...)

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... I do not think this is doable.

> 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.
But if the complete tupple is too long, then you can do either or both of:
 - create an alias, so that symlinks will be created, eg.:
     alias-gcc -> x86_64-blabla-gcc
     alias-ld -> x86_64-blabla-ld
     and so on...
 - provide a sed regexp, eg. 's/^.*-/short-/;' that will create symlinks:
     short-gcc -> x86_64-blabla-gcc
     short-ld -> x86_64-blabla-ld
     and so on...

> Are there any plans to introduce code for building "native" toolchain 
> any time soon? Many thanks!

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.

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? I could see
one reason: using more recent kernel headers and a newer C library to take
advantage of new kernel features (eg. native AIO) that the old C library
was faking (eg. AIO using threads).

Or using a newer gcc that has new optimisations (eg. LTO), or better support
for the CPU (eg. better scheduling, use of specific insns). But is it really
worth the hassle?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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