16.3.2011 16:02, David Paterson kirjoitti:
(snip) .... Or the whole 'newlib' and 'libgloss' sources in the
main GCC source dir if wanting to build newlib at the same time
with the GCC... Then the whole GCC, C& C++ compilers, libgcc,
libstdc++ etc. will be built in only one build stage! Without or
with newlib...
Ah - would I copy the Newlib sources into a specific location? Or
just move the whole directory?
The usual method may be to symlink the 'newlib-a.b.c/newlib' and
'newlib-a.b.c/libgloss' directories to the gcc-x.y.z main source
directory, just like the 'libiberty', 'libstdc++-v3', 'libspp'
are there, or how one puts 'gmp', 'mpfr' etc. there to be configured
and built at the same time with the 'gcc' there (that of course
is what once was the 'GCC sources').
So :
- 'make all-gcc' builds only GCC and its prerequisites
- 'make all-target-libgcc' builds 'libgcc' for the target
- 'make install-gcc' install only GCC
- 'make install-target-libgcc' installs 'libgcc'
There are quite a lot "partial build" choices...
So I guess the instructions being written by newbies who have just
succeeded with their first crosstoolchain and want to share their
"know-how" with others. Not by people who have built 100's of
newlib-based crosstoolchains for some reasons, just-for-a-fun or
for more serious ones...
There aren't actually a lot of examples or instructions around that I
could find, and all of the ones I found ran a full "configure, make,
install" sequence for both the bootstrap and final compiler builds.
I'm sure that, as you say, there a lot of people building cross
toolchains, for a lot of different systems, but the information is
quite hard to find. I don't think I've seen one that does a
single-stage approach as you describe.
The Cygnus people used to have their local 'Cygnus-tree' (GNUPro srcs)
where everything was built only in one stage. Putting the 'newlib'
and 'libgloss' into the GCC sources was instructed many times in many
sites but all people have a little NIH-attitude ("Not Invented Here")
so they like to find other ways to do the same. Maybe they didn't like
to do any copying (pre-install the headers) or any symlinking (put the
'newlib' and 'libgloss' into the "pristine" GCC sources) because that
would be "heretic". I really don't know their reasons, or haven't
understood the reasons at all :( In any case having 'newlib' and
'libgloss' with 'gcc', 'gas', 'bfd', 'opcodes', 'libiberty' etc. as
subdirectories in the same sources, isn't anything new or innovative,
just old practice.
In the 1990's and early 2000's the cross GCC builds were done in
a single stage for both system and embedded targets, because :
- the system target usually was some existing (proprietary or
custom) system with its prebuilt and thoroughly tested target
libraries
- the embedded target usually was some newlib based system
But with 'crosstool*' the situation changed to :
- the system target usually was some unexisting Linux system
which would be created with the new crosstoolchain
- the embedded target usually was some unexisting Linux system
but creating it required some 'bare-elf' toolchain using
newlib as the virtual C library. The '-linux-uclibc' cases
maybe were these
So in order to get the newlib-based crosstoolchains integrated into
the same 'crosstool*' method, there should be just the same phases,
"bootstrap GCC", producing the C library and producing the final GCC :(
But still people have full freedom to follow the old methods, to
build a crosstoolchain in only one stage for some existing target
system and also for some newlib-based embedded system. No reason
to mix the 'crosstool*' ideology into these builds...
So although the build with the generic newlib headers will work,
there is that suspect: "It cannot be this easy, something must
be wrong!". For the paranoids there are the steps :
1. build and install only GCC and libgcc
2. build and install newlib
3. continue the GCC build process via 'make ; make install'
Hmmm, now one of the reasons I've followed the two stage approach is
that I ran into a build problem doing something like this. After a
bit of googling and experimenting, the solution appeared to be to
delete everything in the build directory before rebuilding the
compiler. (I can't remember exactly what the error was, but I can try
to reproduce it if you're interested.)
The commands needed for 1. were told earlier. After the newlib
build and install the later things should succeed without any
problems, from where the things were left... But maybe I have
forgotten something like that the 'fixinc' would happen anyhow,
whether there are target headers available or not...
But also these steps will produce the GCC only once, continuing
after a short coffee break for the paranoid's nerves...
Of course if one puts the 'newlib' and 'libgloss' among the GCC
sources, then everything should appear during the first build
and be fully right!
OK - I may try this, but as I mentioned above, which directory should
I put the sources in?
Into the main 'gcc-4.5.2' or something directory as 'newlib' and
'libgloss' there, extracted from the 'newlib-1.18.0' or something
via symlinks or copying. I would suggest symlinks and removing them
immediately when they aren't needed any more. Having them there will
cause weird problems if the sources are configured for some non-newlib
target and even not using '--with-newlib' ! If there is any possibility
that the target could use newlib (newlib and libgloss could be
configured for this), then instead of the right target C library the
newlib headers in the sources will be tried :( I remember this
happening with 'armv7l-meego-linux-gnueabi' or some other target which
had its own prebuilt glibc...
