Re: "building binutils for target" question

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

> So *maybe* it makes sense to build the cros-native toolchain along with
> the cross-toolchain...
>   
It does as I cannot see too many scenarios where someone would want to 
build a "cross" chain and leave it there.

It has to be used for some purpose - i.e. building other programs for 
the target arch - but more often than not these programs are dependent 
on the basic target libraries like glibc, binutils etc so it makes 
perfect sense to build and include these as well as part of the whole 
process.

Of course I have absolutely no idea how much work is required for this, 
because even though I have long experience with programming this is the 
first time I am involved in building a cross toolchain from scratch.

> > Do you envisage any problems if I try to build and install a copy of 
> > binutils for the target in my image root (build=x86_64, 
> > host=target=powerpc) using the cross compiler built by the toolchain? 
> > Would that be a problem do you think?
> >     
>
> Building binutils should be fairly easy. Just be sure to use the exact
> same version and options and patches that were used to build the cross
> toolchain.
>   
Yeah, thought so. Will give it a go and post the progress I've made on here.

> Building gcc might be a bit more delicate... gcc is really not playing
> nice when it is cross-compiled. Hence the time it takes to properly
> finish the canadian-cross patch series I'm working on... :-/
>   
Bugger, so --build=x86_64 --host=powerpc --target=powerpc won't be as 
easy you reckon? I intend to adopt similar steps as when the toolchain 
was build - static gmp, mpfr, then ppl, cloog,  and binutils, after that 
use the already built glibc and try to build "cross-native" gcc (see my 
question on that in the next paragraph).

> Remember that you already have a C library on the target, so you will not
> need to build it again. You will have to tell gcc where to find it.
>   
OK, but, presumably, when I construct that final image glibc should also 
be there (in the final image), right? how do I "move it across"? Where 
is it located (for the target arch)?

> Also, you will want to build gcc without sysroot support, and tell it that
> headers and libs are in /lib. /usr/lib and /usr/include (respectively!).
>   
Presumably these libraries and headers should already be present in 
those directories, right? If so, then I would definitely need to run 
(and install!) gmp, mpfr etc together with binutils and either 
"move/copy" the glibc files from my cross toolchain or build another 
glibc from scratch using the cross gcc built by the toolchain. Does that 
seem plausible to you Yann?

> I've never done this, so I can't really tell whether it is easy or not...
>   
I'll give it a go as it is my first time for me as well ;-)

> > One additional query - ct-ng starts with installing the kernel headers 
> > and by what I looked at they are in sysroot.
> >     
>
> Yes. For Linux-based systems, kernel haeders are required to build the C
> library, because they export the userland API+ABI of the kernel. In the
> Linux world, the kernel does change its userland API+ABI, so that it
> can make use of new syscalls: AIO, splice... So the C library has to
> know what the kernel provides, to be able to use it, or fake it (eg. AIO
> could be faked by use of threads if the kernel does not have it)
>
> But we do not install the kernel headers as-is. We install sanitised
> headers, of which all kernel internals are ripped out, so that only the
> kernel <-> userland API+ABI is exposed.
>
> [...]
> You do not need to copy or install them again. The cross-gcc and cross-ld
> will be able to find them (and the libs) automatically. This is the purpose
> of the sysroot.
>   
What about my "cross-native" gcc and the binutils I am going to build? 
Would they be able to find them (or should I use the --with-headers 
option when running configure, would that be enough do you think)?


MZ

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