This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: building native cross compiler



My target system is Linux, though it would come
with two known variants - LFS (Linux from scratch) and Fedora. It will
be used with both architectures (i586/i686 and ppc).

Targeting to known and existing targets like Fedora/i686 and Fedora/PPC is easy as a pie : Just build binutils, copy the existing target glibc and finally the GCC.
So, if I drop the glibc source in the gcc source tree I should be OK with cross-compiler building is that what you are suggesting?

But a "from scratch" target may involve really
weird attitudes which will disable using any "bootstrap" components
like a temporary replacement glibc for the still unexisting "totally
self built" target system, the "LFS". The famous "crosstool" method
takes it "heretic" to use anything from anything existing in any phase,
only the bare pristine sources are allowed! This is equal to making a
hammer without using any existing hammer during the production, only
a piece of iron and stones tied to sticks... When producing a complete
GCC with libgcc, libstdc++ etc. requires the target C library during
the GCC build for a system target, not being allowed to use some
suitable existing one, makes things really complicated :(
I am not sure what you mean by the above!

So cross GCCs for targets like 'i686-fedora14-linux' and
'powerpc-fedora3-linux' are easy as a pie to build but for targets like
'i686-mydistro-linux' and 'powerpc-mydistro-linux' it would be very
hard to produce tools if one is not allowed (politically) to bootstrap
the first GCCs with the Fedora or something glibcs, thinking them
being only "some" glibcs for the generic 'i686-linux-gnu' and
'powerpc-linux-gnu' target cases...
I will bootstrap the first compiler - GCC1, which is then going to be used to build GCC2 (the cross-compiler) and GCC2 will then have to build the entire target system (including another copy of gcc - GCC3, which will be solely used to build software on the target system only). I have no alternative with this, unfortunately!

Just as well as the equivalent
prebuilt Debian, Ubuntu, SuSE etc glibcs for i686 and PPC... Producing
glibcs with fully working GCCs is the default, the default for a glibc
build is a native build and nobody says that one is not allowed to have
any stuff in '/lib', '/usr/include' and '/usr/lib' then (some existing
old glibc)...
I assume you understand that my host system will *always* be x86_64 and will *always* be Fedora - just in case I wasn't clear with this. So, can I build glibc for system other than the host one or is this rapidly becoming chicken-and-egg scenario?


From what I gather by reading the INSTALL (and FAQ) files from the
source archives I would need to build glibc separately, after I built
binutils, use the same prefix and probably specify the "--with-headers"
option as well. I take it glibc won't be relying on the GCC
cross-compiler otherwise we have a chicken-and-egg scenario on our hands?

Maybe the "proprietary" targets like Sparc/Solaris, AIX, SVR4 etc. and "custom" ones like FreeBSD, NetBSD, OpenBSD, Cygwin, MinGW etc. could serve as models for normal targets for cross binutils, GCC and GDB. They already have their own original fully tested headers and library binaries without sources or with sources but no sanity to reinvent the wheel by trying to produce something identical for the existing...
LFS does have sources (and I presume headers too), but in order to build it I need GCC2 fully functioning, which is what I am trying to do as both host and target systems are different.

There are a couple of paragraphs from the same file which I am not sure of:

"You must first build the library (`make'), optionally check it
(`make check'), switch the include directories and then install (`make
install'). The steps must be done in this order. Not moving the
directory before install will result in an unusable mixture of header
files from both libraries, but configuring, building, and checking the
library requires the ability to compile and run programs against the old
library."

Do I need to do this as i am building with a specific prefix and, I take
it, my original system won't be affected (I won't be chrooted yet). If I
do need to follow that what does the 'switch the include directories' mean?


"You may also need to reconfigure GCC to work with the new library.
The easiest way to do that is to figure out the compiler switches to
make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
work on GNU/Linux systems) and use them to recompile gcc."

Do I need to do that too? If so, should I specify the --dynamic-linker
path to "prefix/target/lib/ld-linux.so.2"?

All this stuff has nothing to do with producing a normal cross GCC for a normal already existing target like a Linux distro, Fedora, SuSE, Ubuntu etc. !
So, I should disregard this then...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]