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: Problem building cross-gcc for powerpc-linux


"William A. Gatliff" <bgat@billgatliff.com> wrote:

> I've been looking at the problems in libgcc2.c, they're the ones that
> make the ppc-linux target impossible to bootstrap.  No obvious fixes
> in mind yet, unfortunately.

 As people surely remember, I have considered these problems being
only "attitude problems" and people can blame themselves if wanting
to struggle with them...

 Meanwhile the people who build a 'powerpc-linux' target GCC in the
native Linux/PPC platform, have the 'target headers and libraries'
in their expected places ('/usr/include' and '/usr/lib' plus '/lib'
there), some cross-GCC builders building for this same target will
continuously try to avoid installing any 'target headers and libs'
before starting to build their GCCs, whatever problems this will
cause them... Do the Linux/PPC-developers care ?  Of course not,
stupidity is always stupidity and when the GCC-manual tells that
those headers and libs must be there and people don't believe,
what one can then do than let them try their tricks...

 An equivalent case would be when a Linux/x86 user would like to
produce a toolchain which is optimized for Athlon. The built
compiler binaries should be optimized for Athlon and the built
glibc should be optimized too. So the configure command could be
like:

 .../configure --build=i386-redhat-linux --host=i386-redhat-linux \
 --target=i686-linux-gnu --enable-shared --enable-threads

and a cross-GCC from the native plain vanilla 'i386' Linux to the
'i686-linux-gnu' target (because no default for Athlon exists) would
be produced. The 'CFLAGS' used during the build must be tailored with 
a suitable '-march=athlon*' option too...

 The new cross-GCC will reside in:

  /usr/local/i686-linux-gnu/...
and
  /usr/local/lib/gcc-lib/i686-linux-gnu/<gcc-version>/...

because no '--prefix=' was given...

 If the builder in this case denies to copy the 'target headers and
libs' from '/usr/include' into '/usr/local/i686-linux-gnu/include'
(plus make the 'limits.h'-symlink) and copy the stuff from '/lib'
and '/usr/lib' into '/usr/local/i686-linux-gnu/lib', it would be
quite stupid. Just as stupid as not copying stuff for Linux/PPC
from some Linux/PPC distribution when producing tools for
'powerpc-linux-gnu'.

 Quite similar reasons as in this Athlon-case ('i386' libs cannot be
used with 'athlon-xp') may cause some misunderstandings like that
'generic' PowerPC libs cannot be used with some PPC-variant when
one finally uses the built 'powerpc-linux' toolchain. This really
is not the question, but whether this works during the GCC-build.

 As is well-known, the GCC-build needs the target headers for
possible fixing and for compiling the produced libraries. And
needs the target libs for linking the produced shared libraries
like 'libgcc_s.so' and 'libstdc++.so'. That the 'bootstrap' C-
library is for the wrong CPU-variant doesn't really matter, not
in the native-GCC case, not in the cross-GCC case.  If one could
try to avoid using the target headers and libs in the native
case by removing the stuff in '/usr/include' and '/usr/lib' so
that the new GCC couldn't use them, what this could have as the
result?

 The defaults for builds in the GCC sources are the native case
('update the current GCC' or 'make an alternative for the 'cc')
and 'update the current GCC' in the cross-GCC case. In both
cases the old C-library for the target is in its place before
starting. If one makes a log from a glibc-configure, one sees
that the 'current glibc-headers' will be checked, so just the
same 'native/update' assumptions will be used there... For the
99.9 % of the builders these really must be the cases because
so few problems coming from the 'updaters' will be seen here...

Cheers, Kai


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