This is the mail archive of the crossgcc@sources.redhat.com 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]

Re: build trouble, gcc 2.95.3 i868/powerpc cross compiler


"Cameron, Steve" wrote:
> 
> Kai Ruottu wrote:
> 
> >  What kind of religion or attitude disables you to copy a prebuilt
> > glibc from the target machine or from some other Linux/PPC system
> > or from a Linux/PPC distribution on the net (SuSE PPC,
> > YellowDog,...) ?
> > Then build GCC using it and then possibly updating glibc from its
> > sources?  If one wants to build everything from sources, 'start from
> > scratch', this is the easy way.
> 
> No attitude or religion.  It's for an embedded system.
> I tried with newlib because of this page:
> http://penguinppc.org/embedded/cross-compiling/
> which references "--with-newlib", and also this page:
> http://shorterlink.com/?TNTVV7 and others like it,
> which claimed to solve the specific problem I was seeing.

 Perhaps the idea about not using anything else than the sources is
one kind of religion, or misunderstanding the target libraries being
host-dependent because GCC and binutils for the target are, but anyhow
using newlib in the bootstrap process sounds a little weird...

 With gcc-2.95.3 things are still easy, only target headers are needed,
but gcc-3.x requires the C-library with its startups for linking the
shared 'libgcc_s.so'. Then all kind of tricks will be needed. Not any
rocket science, but who cares to teach these tricks all the time or to
try to find new ones, when doing this thing mimicking the native Linux
situation is much more easy... One may need tricks when building one's
first GCC+glibc combination, but documenting the tricks and expecting
others to do the same 'reinventing the wheel' is a bad joke. I did my
stuff because downloading those big (usually 10 M + 10 M RPMs) packages
wasn't quick enough and building a newer generic glibc was my aim...
And I somehow expected to be able to build them without asking any help.
One needs the tricks only when building the first toolchain for a
Linux/CPU, and not if a glibc for the Linux/CPU is available. I can
stand the pain, but don't expect others to share it with me... All the
people having rapid net connections are free to choose the easier way.

 Some new/old tricks here:

 The 'newlib as the workaround-library where to find some headers'
isn't the only possibility if not wanting to use a prebuilt glibc
during the GCC-build...

 With gcc-2.95.3 one could simply copy the native Linux-headers from
the '/usr/include' and copy the CPU-dependent headers from the
'sysdeps/*/powerpc/bits' and the 'sysdeps/*/powerpc/sys' in the glibc-
sources into the '$prefix/$target/include/bits' and
'$prefix/$target/include/sys' for the target and then get a working
'libgcc.a' at the first try and 'make all-gcc' to succeed...

 Copying the 'native Linux-headers' in a Solaris2 etc. build platforms
of course isn't possible... 

 Or the most simple solution would be to not build 'libgcc.a' at all in
the bootstrap phase to get only a C-compiler. The 'make all-gcc'
tries to build this, but computers are stupid, so it is also possible to
use a 'touch libgcc.a' in the '$build/gcc' subdir after the libgcc-build
needs some target headers and crashes. So letting 'make' be happy with
the produced empty file... Maybe a 'touch libgcc2.ready' will be needed
to 'stamp' the situation, or using the same for 'stmp-multilib' because
it tells when all the needed 'libgcc.a's are built for targets needing
multiple 'libgcc.a's (some Linux'es may try this)... So again the build
to get a GCC may 'succeed', now WITHOUT any headers...

 I have used the 'copy the glibc headers from a Linux distribution using
the same glibc-version', ie. building glibc for some other CPU which has
GCC ready, not for the native system, and then copying the headers from
the installation into another for another CPU and then replacing the CPU-
specific headers with ones for the another CPU...

 Hmmm, one possibility would be to search for a prebuilt GCC for the host
and target combination, for instance Linux/MIPS has many, Linux/SH too,
probably Linux/PPC too (RedHat EDK had RedHat 6.x-to-Linux/PPC and this
should work under 7.x. A prebuilt glibc-2.1.2 too) and then use it to
build glibc from sources... Getting a 'bootstrap-GCC' from the net is
quite normal when no native 'cc' exists (Solaris2'es).

 All the FAQs in the net are only opinions from different people, there
are always many ways to do the same thing and one may prefer something
to something else...

 I got my opininion about using always the right stuff after putting
liquid aimed for hand-washing into a dish-washer machine because the
right liquid bottle was empty... And then got a reall mess in the
kitchen and quite a lot nagging afterwards... As it was told to me, no
sane person could use wrong liquid there. But who would expect an
engineer being sane ?  The only other person who I know having done the
same, was also an engineer... Meanwhile I have never heard anyone putting
92-octane gasoline into a car needing 99... How on earth people know that
this could cause a mess or some big noise ?  Ok, using the right stuff
everywhere unless surely knowing that the 'wrong stuff' will work too,
is my recommendation...

 For instance my experience says that a brandy made elsewhere in France,
not in Cognac or in Armagnac, cannot very easily be recognized to not be
real cognac or real armagnac, or that the taste is worse. Many people
cannot taste the difference, so suggesting them to get VSOP brandy instead
of VSOP cognac may be fully possible... The "Hitchikers Guide to the
Galaxy" recommends real armagnac, but if one cannot taste the difference...
Recognizing a bourbon from a scotch, although they both are 'whiskey's,
however isn't hard...

 Things may get very complicated if one builds GCC with newlib, gets a
garbage-libgcc.a, then builds a glibc which scans the produced 'libgcc.a',
links against it when producing 'libc-2.2.x.so', 'libm-2.2.x.so' etc. Then
also the produced glibc binaries are garbage, only the headers should be ok.
Then one must build GCC again to get a working 'libgcc.a' (but not necessarily
a working 'libgcc_s.so' because the '.so's in glibc were broken) and finally
build glibc again to get working glibc binaries... And then GCC once again...
Maybe one must do once iteration again to check the results... To much work
and a real mess for all the lazy people who would rather use their time for
trying to decide whether an armagnac tastes better than a cognac...

 Ok, producing GCC uses only the build/host headers, but producing 'libgcc.a',
'libiberty.a', 'libstdc++.a' etc. uses the target headers. One cannot use
mostly wrong headers for these...
 
 "A Linux is a Linux, although one would fry it (embedded) in butter",
or something... AFAIK all the syscalls etc. are the same for the same CPU.
The kernel may vary but all the tools around the kernel can be the same.

 The IBM-PC age teached that it is not enough to have MS-DOS in the 'PC',
also the HW must be identical with the 'original PC'. The 'Wang-PC', 'HP-150',
'NCR-PC', 'Nokia-MM2' etc. were sad examples about 'non-compatible-PC's
using MS-DOS...  Compaq however was one of the first to understand the
importance of 'hardware compatability' in the PC-business... I remember
the 'comp' meaning both 'compatability' and 'compactness', the first
'sewing-machine'-like PC perhaps wouldn't be very 'compact' now...

 There shouldn't be any HW-dependency in the Linux-business, an old
non-compatible 'Altos/386' bought with Xenix/386 should be capable to
run Linux/x86 with all its tools, if drivers for its HW would exist
in the kernel. In the PowerPC-area no HW-compatability needs should
either exist.

 So the compiler tools should produce code for Linux, not for some
specific HW, and the compilers and glibc should be HW-independent...
So any prebuilt glibc as the C-library for Linux would be suitable
to start with, before one knows what special things would be needed
in the kernel. Or some new feature existing in the C-library...

 Ther may be some dependency between the kernel version (2.4.x now)
and the glibc version (2.2.x needed for 2.4.x ?), so although GCC
could be built against glibc-2.1.x, updating glibc later may be
necessary. But rebuilding GCC against/with glibc-2.2.x probably not.

 Having some glibc helps the GCC-build and when the 'Catch-22'
situation never is a joy, one really doesn't want to struggle with
it with every GCC-update. When one gets glibc built for something,
it is not sane to throw it away before the update. Having glibc
already built earlier is the 'normal' situation, not that it doesn't
yet exist. Or people build GCC and glibc only once in their life.
My 'glibc-2.2.4' may be third or fourth reincarnation after the
first '2.0.6' or something for Linux/PPC... It never came into my
mind to throw away the existing glibc before a GCC-update, how
weird when all the FAQs expect every GCC-builder to do just this.

 If I have misunderstood all this, please someone correct me.

> Also, I didn't have a usable target machine or a distribution,
> it's an IBM walnut 405GB, a pretty bare bones system: processor,
> memory, network, serial port, nothing more.  Hence the need
> for a cross compiler.

 Basically the sources and binaries for the MontaVista (www.mvista.com)
'embedded Linux' distributions should exist, the RedHat's EDK ('Embedded
Development Kit') for embedded x86 and PPC was withdrawn. I mention
these if someone wishes the prebuilt stuff being 'embedded oriented'...
It really doesn't need to be (first).

 The plain-vanilla Linux kernel sources should support all kind of HW,
but maybe MontaVista has more drivers for more HW...

> Anyway, I did get the cross compiler to build finally, but it sounds
> like I should probably build it again with glibc.

 Yes, you will need the preinstalled glibc-headers for the target libs.

> What I was doing wrong (well, _one_ thing I was doing wrong)
> was trying to build gcc from inside the source directory,  I
> didn't realize you weren't supposed to do that.
> (on account of the fact that I'm an idiot)

 Maybe you didn't do anything definitely wrong... In your case the tools
probably will be used to produce Linux for a new HW, not Linux apps for
some Linux-distribution. Producing 'apps' is easier, but producing 'Linux'
means that the produced 'glibc' is partly an 'app', the shared libs will
be installed into target system, also the utilities produced during the
glibc-build... So glibc must be produced for the native environment, not
for the cross-environment. The 'penguinppc' instructions about using
the '--prefix=/usr' for glibc, but being very careful during install are
all sane... Although the instructions for the GCC-build maybe aren't...

 Practicing with copying a native glibc from the native environment into
the cross-environment, before doing this vice versa, may be useful... So
this would be one more reason for using a prebuilt glibc from some native
environment using Linux/PPC there... Small things like '/lib/ld-linux.so.2'
in Linux/x86 being replaced with '/lib/ld.so.1' in Linux/PPC, but some
time one must learn all these...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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