14.3.2011 20:03, Michael Zintakis kirjoitti:
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?
Of course not! The existing targets ALREADY HAVE their C libraries
built and thoroughly tested! So why on earth anyone would try to
reinvent the wheel? The binutils and GCC binaries and the extra
target libraries produced during the GCC build using these new
"apps" don't exist in the beginning but all the glibc, X11, Gnome
etc. libraries for the target are already there! Are you really
seriously trying to reproduce all this glibc, X11, Gnome etc. target
stuff?
I am not sure what you mean by the above!
That when one only wants a crosstoolchain for instance for Fedora 14
x86_64 when having Ubuntu 10.04/i586, then one just builds binutils
and GCC with their associated target libs built during the GCC build.
BUT doesn't build any of the already existing Fedora 14 x86_64 target
stuff like its original target libraries, only copies them onto the
cross host into a suitable $sysroot...
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!
Producing the GCC2 would normally happen via using the GCC1 as the build
and host compiler which uses the '/lib', '/usr/include' and '/usr/lib'
during compile and link. These will not be replaced with something made
with the GCC1 after it is ready. The GCC2 will need its own 'lib',
'usr/include' and 'usr/lib' stuff in the $sysroot when configuring the
'libstdc++' etc. GCC-version-specific target libraries and when
producing them... From where these will come is the bad ideological
problem :( Can one simply copy these from some existing "similar" (to
the becoming target) system? Or is that "heretic"? Is one allowed to
use the existing native GCC to produce the GCC1?
I cannot tell what you may do or may not do... For me a component taken
from some existing is fully legal and sane and doesn't differ from using
some existing build and host systems and components from them. The
world just is such that people don't need to produce tools and temporary
components from scratch before they will be replaced with self-made
ones.
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?
Yes you can but there may be requirements for the tools being used. For
instance that the GCC used to build glibc needs to be capable at least
to produce a "Hello World" app for the target, have a 'libgcc' with has
support for threads, exception-handling etc.
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.
So the BIG question is : "Are you allowed to produce a complete and
working GCC2 which has a prebuilt temporary glibc as the target glibc
in some stage?" The process would be :
1. make binutils for the target
2. copy a temporary glibc for the target
3. make GCC for the target
4. make the final glibc for the target with the step 3 GCC and
overwrite the temporary glibc
Trying to avoid the step 2 in a LFS case although the GCC build
expects the target C library being already there, is just what
the "crosstool" process is for... And is equivalent to the problem
"Can I borrow a knife from a neighbour or buy a knife if I want to
make my own self-made knife?" Producing the wooden handle for the
knife without a knife could sound quite hard :(
These ideological issues can make simple processes being very hard.
Maybe I'm an "opportunist" when just using what one has and not
understanding why using it is not allowed by some policy :(
So, I should disregard this then...
If the previous 4 step process can be freely used... The goal is to
make first a working cross GCC which can produce apps for the
"virtual" target, first it can be some existing, later some self-
made (to be produced for which the self-made glibc is the first
step, its runtime parts would go to the target system).
