This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ 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] |
So *maybe* it makes sense to build the cros-native toolchain along withIt does as I cannot see too many scenarios where someone would want to build a "cross" chain and leave it there.
the cross-toolchain...
Yeah, thought so. Will give it a go and post the progress I've made on here.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.
Building gcc might be a bit more delicate... gcc is really not playingBugger, 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).
nice when it is cross-compiled. Hence the time it takes to properly
finish the canadian-cross patch series I'm working on... :-/
Remember that you already have a C library on the target, so you will notOK, 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)?
need to build it again. You will have to tell gcc where to find it.
Also, you will want to build gcc without sysroot support, and tell it thatPresumably 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?
headers and libs are in /lib. /usr/lib and /usr/include (respectively!).
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 ;-)
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)?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.
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |