Re: Making the gcc-2.95.2 Crosscompiler for Linux RedHat 6.1 Host.

[karuottu at freenet dot hut dot fi (Kai Ruottu)]

On Fri, 26 Nov 1999 05:45:18 +0000, Opinionated
<opinionated@whoever.com> wrote:

>Please, no more lectures on how to get the header files over to make the
>gcc-2.95.2 Crosscompiler.

 Sorry for that, but the whole thing is so easy if only the basic
things for all GCCs are known:

 1. Install the target headers and libs into
      <prefix>/<target>/include
    and
      <prefix>/<target>/lib
    where the <prefix> is the '--prefix=<prefix>' and the <target> is
    the '--target=<target>' given when configuring BOTH binutils and
    GCC. So you MUST use the same names for them both, or if it isn't
    possible, to use the values given to GCC-configure when installing
    the target libs & headers. Remember it is just one 'cp' command to
    copy the headers from the newlib sources into the proper place,
    e.g. :

       cp -d -p -r -v newlib/libc/include /usr/local/powerpc-elf

    written in the current newlib-1.8.2 main dir will do it... (Of
    course the parent dir, '/usr/local/powerpc-elf' must be created
    earlier)

2.  Configure binutils, build them with 'make' and copy them into
      <prefix>/<target>/bin
    Sometimes one cannot use the same '--target=<target>' as with GCC
    and 'make install' will then install them to wrong place for GCC.
    Then copying them manually just where GCC will need them is the
    sure way...

3.  Configure GCC, build it with 'make', hoping that everything will
    go ok. At least all the stuff in the 'gcc'-subdir should build ok
    if the target headers are where they should be
    (in '<prefix>/<target>/include').
 
    Building the extra libs (libiberty, libobjc, libstdc++) may cause
    problems when there aren't any libraries and startup for the
    target yet. One cannot produce executables without them and the
    'libiberty'-build wants to scan the current C-library, seeking
    what is missing.

    If there are any problems with the target headers, there is always
    the '-print-search-dirs' option for GCC for debugging the
    situation...

    And if one cannot remember the '-print-search-dirs', remembering
    to use the '-help' or '--help' with GCC will refresh ones memory.

    E.g. './xgcc -print-search-dirs', written in the build dir will
    tell which are the natural 'search paths' for the new GCC. (Adding
    the '-B./', which it uses during the build, will add the build dir
    into the search paths.)


 For embedded targets like 'powerpc-elf' (why not 'powerpc-eabi',
which is the normal target name for embedded PowerPC-ELF?), one
needs to build the Cygnus newlib for the C-library, or download
prebuilt libs from 'www.objsw.com' etc...

 If building newlib is 'the right way', one can either install the
GCC-parts manually, copying the 'xgcc' and 'g++' into proper names in
the PATH, like :

  /usr/local/bin/powerpc-elf-gcc
and
  /usr/local/bin/powerpc-elf-g++

(If one used any '--prefix=<prefix>', using the '<prefix>/bin' instead
of the default-prefix, '/usr/local', is natural)

 And then copy the 'cc1*', '*crt*.o', 'include', 'libgcc.a', 'specs',
'*/libgcc.a' etc. into:
  <prefix>/lib/gcc-lib/<target>/<version>

 When the necessary compiler parts have been installed, one can build
the newlib, configuring it just like binutils and GCC, and install its
binaries, startups etc. into the already wellknown

  <prefix>/<target>/include
and
  <prefix>/<target>/lib

 Then one can (normally) continue with building the extra libs in
GCC, install them and be very happy...

 Another way is to try to get all the stuff with just one 'configure':
copy the 'newlib', 'bfd', 'opcodes', 'libgloss' etc. subdirectories
into the same directory hierarchy, and try to build binutils, newlib
and GCC, all at the same time. This is the way all those
'cross-gcc'-patches may hint. But this may just lead to a big mess... 

 I prefer the method to take one part at a time and fully
understanding what is now happening. Later when one thinks him/herself
an experienced builder, all these tricks for automatizing the build
job may be tried...

 The PowerPC-EABI (probably '-elf' is the same) needs fixing the
'gcc/specs', to add some real target like the psim-simulator or any of
the supported PPC target boards, to be as the default target system.

 There are no 'default target' for PowerPC, as there is for 'sh-hms',
'h8300-hms', 'arm-elf', 'fr30-elf' etc. embedded targets with probably
only one supported target board/system, or a simulator which simulates
the same board/system.

 For system targets like 'powerpc-linux-gnu', everybody understands
that the 'target system' is fully defined. But for embedded targets
with no PC-like hardware standard, not even a common operating system
defining the stardard, this situation with PowerPC should be more than
expected.

>First, Please Understand my Environment:

 The build/host-system may sometimes have problems with the
GNU-sources, but your target name seems to be the problem here...

>+ I have made a cross bin-utils tools for the powerpc-elf target
>(Host=i686-gnu-linux, Target=powerpc-elf).

 So your target is an embedded system, not 'powerpc-linux-gnu' ?

>    2.  cd /usr/local/powerpc-elf/sys-includes

 The 'sys-include' is just a curiosity and can be forgotten in this
phase... (IDP-people may put their Oracle-headers there...)

>    3.  Correct linux link to point to /usr/src/linux/include/linux and
>asm link to point to /usr/src/linux/include/asm-ppc
>
>    4.  Create the bit subdirectory in
>/usr/local/powerpc-elf/sys-includes/ and populate it with the powerpc
>headers, generic, and system V /bit header from glibc-2.1.

 What the hell this means? Why you try to use the Linux-headers etc.
Linux-stuff for the embedded PowerPC-target, when your target is not
Linux/PPC at all?

>+  After compiling for a few minutes I come to a hard stop on compiling
>/gcc2.95-2/libiberty/strerror.c:461 previous declaration of
>'sys_errlist'
>
>I know how to look up previous declarations, but, come on, why don't the
>declarations completely match to begin with?  Or, as you see what I'm
>doing, what libraries are conflicting?

 So you perhaps don't want make a cross-toolset for producing code for
routers, industrial controller etc., but for some Linux/PPC-system...

 If you really want a x86-linux-gnu-x-powerpc-linux-gnu toolset, why
on earth you configure with using a target name for an embedded
PowerPC toolset?

 For Linux/PPC the easy way is to download the current glibc-2.1 etc.
binary distribution, install its headers and libs (and fixing the
links in them) to the '<prefix>/target>/include' etc., and configure
and build binutils and GCC for 'powerpc-linux-gnu' target. But I
remember one needing newer binutils snapshots, which recognize the
target name. Older ones may approve only 'powerpc-elf' or something,
but what about generating shared binaries with them... Rebuilding
glibc for Linux/PPC from current sources may wait (or one can expect
someone else to build it and put it available too...;-)

 For discussion about problems with the Linux/PPC-cross-toolset, I
just refer to the 'crossgcc'-maillist archive available via:
   http://sourceware.cygnus.com

 All the problems (with 'libc.so' being a script, needing to add a
'-rpath-link' to specs, fixing the symbolic links etc.) are just
too long to be handled here again... You will find addresses for
people who already have a x86-linux-gnu-x-powerpc-linux-gnu toolset
in use.

Cheers, Kai