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

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

[Opinionated]

Please, no more lectures on how to get the header files over to make the
gcc-2.95.2 Crosscompiler.  I have gone through Hell trying to get
everything only to get down to another error in a duplicate defined
variable that is not declared the same.  I'll explain more in a minute:

First, Please Understand my Environment:

+  Redhat 6.1 Linux setup with kernel-2.2.12-20 on an Pentium II 366 Mhz
Machine (aka i686)

+ System Include files are in /usr/include  with /usr/include/linux ->
/usr/src/linux/include and /usr/include/asm ->
/usr/src/linux/include/asm

+ I've had to download full sources for kernel-2.2.12 (Installation
Source only has includes for just the i386 host), gcc-2.95.2,
binutils-2.9.1, and glibc-2.1.

+ I have made native bin-utils and gcc for my system
(Host=i686-gnu-linux, Target = i686-gnu-linux) successfully.

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

+  Steps I use to make the gcc Crosscompiler:

    1.  In build directory:  ../gcc-2.96.2/configure
--target=powerpc-elf --use-with-headers=/usr/include -v
          (--prefix=/usr/local/powerpc not included since pointing the
prefix to any other directory than /usr/local
             makes the bin tools unaccessible to the compiler).

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

    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.

    5.  make (as specified in the GCC document).

+  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?

I can't believe I can't get a crosscompiler for my machine.  I have
looked at links and practically all of them are how to configure
Host=Win32 Cygwin tools to something (which makes the directories to use
easy) and am discovering that this does me absolutely no good.  I'm very
frustrated.

Anyhow, someone please shed some light on this for me.

Thanks again in advance for any help (excluding the lecture on how I
should find where the header files should be used).

========================

Kai Ruottu wrote:

> On Wed, 17 Nov 1999 04:09:05 +0000, Opinionated
> <opinionated@whoever.com> wrote:
>
> >Hello All,
> >
> >I was having one specific problem compiling a cross-compiler for
> gcc.  I
> >finally got a cross-compiler on gcc-2.8.1 after I finally found the
> >patch which clears up a 'can't find stdio.h' error.  I have noticed
> that
> >gcc-2.95.2 has the exact same problem.
>
>  When you most probably need a C-library for your compiler, with the
> <stdio.h> etc. headers, I see your problem being not having the
> C-library binaries or sources when starting to build GCC. For 'system'
>
> targets the proprietary headers and libs for the system are mostly the
>
> only alternative, but Linux has the glibc-2.x.x binaries and sources
> and embedded systems have the Cygnus newlib sources...

<snip>

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

[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

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

[Kai Ruottu]

On Fri, 26 Nov 1999 15:14:49 GMT, karuottu@freenet.hut.fi (Kai Ruottu)
wrote:

>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.

 I apologize the 'lecture' again, but as the matter of fact, knowing
the basic rules will help solving the problem...

>>+  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'

 The 'crossgcc' mail-list should have a (unanswered?) message from
Jessica Brown, which describes the same error, in the same row... So
let's handle this after having studied the 'lecture'.

 The Jessica's message shows that the offending line (461) will be
used if the HAVE_SYS_ERRLIST is not defined. This should be defined
in the 'config.h' or something in the libiberty subdir.

 As the 'lecture' said, for libiberty is a search tried in the current
'libc.a/libc.so', to see what is missing from it. When you don't have
the 'libc.a/libc.so' for the target, it doesn't know anything about
it. So it thinks there isn't a symbol with the name 'sys_errlist' in
your 'libc.a/libc.so' and the HAVE_SYS_ERRLIST will be left undefined.
It doesn't search anything from the target headers (although one would
wish that...).

 So you must use a 'grep HAVE_SYS_ERRLIST *.h' in the libiberty
subdir, to see which of the automatically generated config headers
must be fixed (I remember it being the 'config.h'). There may become
other errors just like this, resulting purely from the unexistence of
any libraries for the target system... So going the 'config.h' through
and fixing all the definitions there, is a substitute for the work
that the configuration scripts could have done if you had the libs.

 So, whether your target is an embedded 'powerpc-elf' or the Linux/PPC
'powerpc-linux-gnu', it is quite necessary to have pre-built libs
for the target BEFORE trying to build libiberty. So you must build
newlib or glibc after the 'gcc-2.95.2/gcc' is ready, i.e. the compiler
is ready and only the additional libiberty, libobjc and libstdc++
parts are still missing. But much better would be if you had ANY
pre-built libs for the target. Updating the C-library can be left
later.

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

 Perhaps all the extra details for a x86-linux-to-powerpc-eabi or
for a x86-linux-to-powerpc-linux could belong better to the currently
quite quiet 'crossgcc'-mail-list. The site 'www.objsw.com' should have
info about how to join, and perhaps the mail-archive is also there.
Perhaps the Cygnus site hasn't anything about crossgcc any more...

 I strongly suggest downloading the mail-archive and browsing it
through... If you cannot get the archive from the messages in this
year, just send your real mail-address (the 'opinionated@whoever.com'
sounds like an invented one), I can forward all the messages I have in
my mail-archive about the powerpc-target to you...

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

[Opinionated]

Thank you Kai.

My target is indeed in this instance an embedded powerpc system running
VxWorks.  I was trying to get a cross compiler that would at least compile up
to the assembly language source, and perhaps linking in with the VxWorks
objects(but not use the VxWorks headers until after i get the cross
compiler..I don't want VxWorks to be integrated into my cross compiler).
However, I will be perfectly happy to have something at least compile and
look like it is linking, and not really care about the final product since I
will have to recompile my code on a VxWorks tools platform for the final
result.  This would make my life easier though since I could now write and
compile my programs and check that they will compile correctly before
recompiling them again with the VxWorks tools.  (The catch is that VxWorks
uses gnu tools including gcc-2.7.2 and, now, gcc-2.92.).  I know, I could get
a license for their products, but I have other reasons for 'independent'
tools.

I will double check what I am using, and I really appreciate the heads up on
sys_errlist.  Perhaps I'll be running here in a bit.

Thanks again for your help.



Kai Ruottu wrote:

> On Fri, 26 Nov 1999 15:14:49 GMT, karuottu@freenet.hut.fi (Kai Ruottu)
> wrote:
>
> >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.
>
>  I apologize the 'lecture' again, but as the matter of fact, knowing
> the basic rules will help solving the problem...
>
> >>+  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'
>
>  The 'crossgcc' mail-list should have a (unanswered?) message from
> Jessica Brown, which describes the same error, in the same row... So
> let's handle this after having studied the 'lecture'.
>
>  The Jessica's message shows that the offending line (461) will be
> used if the HAVE_SYS_ERRLIST is not defined. This should be defined
> in the 'config.h' or something in the libiberty subdir.
>
>  As the 'lecture' said, for libiberty is a search tried in the current
> 'libc.a/libc.so', to see what is missing from it. When you don't have
> the 'libc.a/libc.so' for the target, it doesn't know anything about
> it. So it thinks there isn't a symbol with the name 'sys_errlist' in
> your 'libc.a/libc.so' and the HAVE_SYS_ERRLIST will be left undefined.
> It doesn't search anything from the target headers (although one would
> wish that...).
>
>  So you must use a 'grep HAVE_SYS_ERRLIST *.h' in the libiberty
> subdir, to see which of the automatically generated config headers
> must be fixed (I remember it being the 'config.h'). There may become
> other errors just like this, resulting purely from the unexistence of
> any libraries for the target system... So going the 'config.h' through
> and fixing all the definitions there, is a substitute for the work
> that the configuration scripts could have done if you had the libs.
>
>  So, whether your target is an embedded 'powerpc-elf' or the Linux/PPC
> 'powerpc-linux-gnu', it is quite necessary to have pre-built libs
> for the target BEFORE trying to build libiberty. So you must build
> newlib or glibc after the 'gcc-2.95.2/gcc' is ready, i.e. the compiler
> is ready and only the additional libiberty, libobjc and libstdc++
> parts are still missing. But much better would be if you had ANY
> pre-built libs for the target. Updating the C-library can be left
> later.
>
> > For discussion about problems with the Linux/PPC-cross-toolset, I
> >just refer to the 'crossgcc'-maillist archive available via:
> >   http://sourceware.cygnus.com
>
>  Perhaps all the extra details for a x86-linux-to-powerpc-eabi or
> for a x86-linux-to-powerpc-linux could belong better to the currently
> quite quiet 'crossgcc'-mail-list. The site 'www.objsw.com' should have
> info about how to join, and perhaps the mail-archive is also there.
> Perhaps the Cygnus site hasn't anything about crossgcc any more...
>
>  I strongly suggest downloading the mail-archive and browsing it
> through... If you cannot get the archive from the messages in this
> year, just send your real mail-address (the 'opinionated@whoever.com'
> sounds like an invented one), I can forward all the messages I have in
> my mail-archive about the powerpc-target to you...

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

[Opinionated]

Please, no more lectures on how to get the header files over to make the
gcc-2.95.2 Crosscompiler.  I have gone through Hell trying to get
everything only to get down to another error in a duplicate defined
variable that is not declared the same.  I'll explain more in a minute:

First, Please Understand my Environment:

+  Redhat 6.1 Linux setup with kernel-2.2.12-20 on an Pentium II 366 Mhz
Machine (aka i686)

+ System Include files are in /usr/include  with /usr/include/linux ->
/usr/src/linux/include and /usr/include/asm ->
/usr/src/linux/include/asm

+ I've had to download full sources for kernel-2.2.12 (Installation
Source only has includes for just the i386 host), gcc-2.95.2,
binutils-2.9.1, and glibc-2.1.

+ I have made native bin-utils and gcc for my system
(Host=i686-gnu-linux, Target = i686-gnu-linux) successfully.

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

+  Steps I use to make the gcc Crosscompiler:

    1.  In build directory:  ../gcc-2.96.2/configure
--target=powerpc-elf --use-with-headers=/usr/include -v
          (--prefix=/usr/local/powerpc not included since pointing the
prefix to any other directory than /usr/local
             makes the bin tools unaccessible to the compiler).

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

    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.

    5.  make (as specified in the GCC document).

+  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?

I can't believe I can't get a crosscompiler for my machine.  I have
looked at links and practically all of them are how to configure
Host=Win32 Cygwin tools to something (which makes the directories to use
easy) and am discovering that this does me absolutely no good.  I'm very
frustrated.

Anyhow, someone please shed some light on this for me.

Thanks again in advance for any help (excluding the lecture on how I
should find where the header files should be used).

========================

Kai Ruottu wrote:

> On Wed, 17 Nov 1999 04:09:05 +0000, Opinionated
> <opinionated@whoever.com> wrote:
>
> >Hello All,
> >
> >I was having one specific problem compiling a cross-compiler for
> gcc.  I
> >finally got a cross-compiler on gcc-2.8.1 after I finally found the
> >patch which clears up a 'can't find stdio.h' error.  I have noticed
> that
> >gcc-2.95.2 has the exact same problem.
>
>  When you most probably need a C-library for your compiler, with the
> <stdio.h> etc. headers, I see your problem being not having the
> C-library binaries or sources when starting to build GCC. For 'system'
>
> targets the proprietary headers and libs for the system are mostly the
>
> only alternative, but Linux has the glibc-2.x.x binaries and sources
> and embedded systems have the Cygnus newlib sources...

<snip>

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

[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

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

[Opinionated]

Thank you Kai.

My target is indeed in this instance an embedded powerpc system running
VxWorks.  I was trying to get a cross compiler that would at least compile up
to the assembly language source, and perhaps linking in with the VxWorks
objects(but not use the VxWorks headers until after i get the cross
compiler..I don't want VxWorks to be integrated into my cross compiler).
However, I will be perfectly happy to have something at least compile and
look like it is linking, and not really care about the final product since I
will have to recompile my code on a VxWorks tools platform for the final
result.  This would make my life easier though since I could now write and
compile my programs and check that they will compile correctly before
recompiling them again with the VxWorks tools.  (The catch is that VxWorks
uses gnu tools including gcc-2.7.2 and, now, gcc-2.92.).  I know, I could get
a license for their products, but I have other reasons for 'independent'
tools.

I will double check what I am using, and I really appreciate the heads up on
sys_errlist.  Perhaps I'll be running here in a bit.

Thanks again for your help.



Kai Ruottu wrote:

> On Fri, 26 Nov 1999 15:14:49 GMT, karuottu@freenet.hut.fi (Kai Ruottu)
> wrote:
>
> >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.
>
>  I apologize the 'lecture' again, but as the matter of fact, knowing
> the basic rules will help solving the problem...
>
> >>+  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'
>
>  The 'crossgcc' mail-list should have a (unanswered?) message from
> Jessica Brown, which describes the same error, in the same row... So
> let's handle this after having studied the 'lecture'.
>
>  The Jessica's message shows that the offending line (461) will be
> used if the HAVE_SYS_ERRLIST is not defined. This should be defined
> in the 'config.h' or something in the libiberty subdir.
>
>  As the 'lecture' said, for libiberty is a search tried in the current
> 'libc.a/libc.so', to see what is missing from it. When you don't have
> the 'libc.a/libc.so' for the target, it doesn't know anything about
> it. So it thinks there isn't a symbol with the name 'sys_errlist' in
> your 'libc.a/libc.so' and the HAVE_SYS_ERRLIST will be left undefined.
> It doesn't search anything from the target headers (although one would
> wish that...).
>
>  So you must use a 'grep HAVE_SYS_ERRLIST *.h' in the libiberty
> subdir, to see which of the automatically generated config headers
> must be fixed (I remember it being the 'config.h'). There may become
> other errors just like this, resulting purely from the unexistence of
> any libraries for the target system... So going the 'config.h' through
> and fixing all the definitions there, is a substitute for the work
> that the configuration scripts could have done if you had the libs.
>
>  So, whether your target is an embedded 'powerpc-elf' or the Linux/PPC
> 'powerpc-linux-gnu', it is quite necessary to have pre-built libs
> for the target BEFORE trying to build libiberty. So you must build
> newlib or glibc after the 'gcc-2.95.2/gcc' is ready, i.e. the compiler
> is ready and only the additional libiberty, libobjc and libstdc++
> parts are still missing. But much better would be if you had ANY
> pre-built libs for the target. Updating the C-library can be left
> later.
>
> > For discussion about problems with the Linux/PPC-cross-toolset, I
> >just refer to the 'crossgcc'-maillist archive available via:
> >   http://sourceware.cygnus.com
>
>  Perhaps all the extra details for a x86-linux-to-powerpc-eabi or
> for a x86-linux-to-powerpc-linux could belong better to the currently
> quite quiet 'crossgcc'-mail-list. The site 'www.objsw.com' should have
> info about how to join, and perhaps the mail-archive is also there.
> Perhaps the Cygnus site hasn't anything about crossgcc any more...
>
>  I strongly suggest downloading the mail-archive and browsing it
> through... If you cannot get the archive from the messages in this
> year, just send your real mail-address (the 'opinionated@whoever.com'
> sounds like an invented one), I can forward all the messages I have in
> my mail-archive about the powerpc-target to you...

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

[Kai Ruottu]

On Fri, 26 Nov 1999 15:14:49 GMT, karuottu@freenet.hut.fi (Kai Ruottu)
wrote:

>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.

 I apologize the 'lecture' again, but as the matter of fact, knowing
the basic rules will help solving the problem...

>>+  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'

 The 'crossgcc' mail-list should have a (unanswered?) message from
Jessica Brown, which describes the same error, in the same row... So
let's handle this after having studied the 'lecture'.

 The Jessica's message shows that the offending line (461) will be
used if the HAVE_SYS_ERRLIST is not defined. This should be defined
in the 'config.h' or something in the libiberty subdir.

 As the 'lecture' said, for libiberty is a search tried in the current
'libc.a/libc.so', to see what is missing from it. When you don't have
the 'libc.a/libc.so' for the target, it doesn't know anything about
it. So it thinks there isn't a symbol with the name 'sys_errlist' in
your 'libc.a/libc.so' and the HAVE_SYS_ERRLIST will be left undefined.
It doesn't search anything from the target headers (although one would
wish that...).

 So you must use a 'grep HAVE_SYS_ERRLIST *.h' in the libiberty
subdir, to see which of the automatically generated config headers
must be fixed (I remember it being the 'config.h'). There may become
other errors just like this, resulting purely from the unexistence of
any libraries for the target system... So going the 'config.h' through
and fixing all the definitions there, is a substitute for the work
that the configuration scripts could have done if you had the libs.

 So, whether your target is an embedded 'powerpc-elf' or the Linux/PPC
'powerpc-linux-gnu', it is quite necessary to have pre-built libs
for the target BEFORE trying to build libiberty. So you must build
newlib or glibc after the 'gcc-2.95.2/gcc' is ready, i.e. the compiler
is ready and only the additional libiberty, libobjc and libstdc++
parts are still missing. But much better would be if you had ANY
pre-built libs for the target. Updating the C-library can be left
later.

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

 Perhaps all the extra details for a x86-linux-to-powerpc-eabi or
for a x86-linux-to-powerpc-linux could belong better to the currently
quite quiet 'crossgcc'-mail-list. The site 'www.objsw.com' should have
info about how to join, and perhaps the mail-archive is also there.
Perhaps the Cygnus site hasn't anything about crossgcc any more...

 I strongly suggest downloading the mail-archive and browsing it
through... If you cannot get the archive from the messages in this
year, just send your real mail-address (the 'opinionated@whoever.com'
sounds like an invented one), I can forward all the messages I have in
my mail-archive about the powerpc-target to you...