Building GCC as a cross compiler (target=sparc) on RedHat 6.2

Building GCC as a cross compiler (target=sparc) on RedHat 6.2

[Dan Alderman]

Hi,

I've been using GCC on RedHat for some years now, and am begninning to
delv into the realms of cross compilation....  Compiling GCC as a cross
compiler is proving troublesome, can someone help please?

I downloaded the latest stable binutils (2.10.1), gcc (2.95.2) and glibc
(2.1.3) and untarred them in /export/sources/.  I have built all the
packages sucessfully for the native machine (i686-pc-linux-gnu) and they
worked fine.  Trying to build gcc for a different target for the host
machine is when I run into trouble.

I have sucessfully built binutils for the target platform
(target=sparc-elf) and installed them into /export/usr/, and put
/export/usr/bin at the beginning of my PATH.
When trying to build gcc from a directory outside the source tree I get
the following error after a few minutes of building...

../../gcc-2.95.2/gcc/libgcc2.c:41: stdlib.h: No such file or directory
../../gcc-2.95.2/gcc/libgcc2.c:42: unistd.h: No such file or directory
make[3]: *** [libgcc2.a] Error 1
make[3]: Leaving directory `/export/sources/build-gcc/gcc'
make[2]: *** [stmp-multilib-sub] Error 2
make[2]: Leaving directory `/export/sources/build-gcc/gcc'
make[1]: *** [stmp-multilib] Error 1
make[1]: Leaving directory `/export/sources/build-gcc/gcc'
make: *** [all-gcc] Error 2

Is there something I've missed?  I also tried to compile a cross gcc for
the h8300-hitatchi-hms, but got the same errors.

Any help would be greatly appreciated,

Many thanks,

Dan.
=====================================================================
Dan Alderman                Software Engineer OneEighty Software Ltd.

OneEighty Software Ltd.     Phone: +44 20 8263 2333
The Lansdowne Building	    Fax: +44 20 8263 6314
2 Lansdowne Road
Croydon                     Email: d.alderman@180sw.com
CR9 2ER
UK

Under the Regulation of Investigatory Powers (RIP) Act 2000 together
with any and all Regulations in force pursuant to the Act One Eighty
Software Ltd reserves the right to monitor any or all incoming or
outgoing communications as provided for under the Act.

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

Re: Building GCC as a cross compiler (target=sparc) on RedHat 6.2

[Kai Ruottu]

David Korn wrote:
> 
>  Yep. You missed providing the target headers where they can be found
> during the cross-compiler build. Drop them in $prefix/$target/sys-include
> (or perhaps $prefix/$target/include ; there seems to be some disagreement
> between different cross targets on this subject, but sys-include always
> works for me) or add the flag --with-headers=/path/to/headers to your
> configure command line.

 The 'include' versus 'sys-include' seems to be a subject which nobody can
be sure... Mumit Khan, the provider of the official Mingw distribution,
claimed that it is now the 'official way' to put the stardard system headers
into the 'sys-include', and the 'www.gnu.org' instructions talk about 'headers'
which should be fixed by GCC because there is something wrong with them. And
I have tried to strugggle against using the '--with-headers' with newlib in
the GCC-build process... Using the option to point to the Linux-kernel headers
while building glibc is quite a different thing.

 The important thing is where the headers are after the GCC installation. If they
are still in the 'sys-include', this is wrong place for them because the
'sys-include' is meant for the 3rd party/substitute headers. The 'sys-' in the
name comes probably from the macro used with the native compiler :

------------------------------ clip ------------------------------------
SYSTEM_INCLUDE_DIR
  Define this macro as a C string constant if you wish to specify a system-
  specific directory to search for header files before the standard directory.
  SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR in the search order.
------------------------------ clip ------------------------------------

while the equivalent for the 'include' is :

------------------------------ clip ------------------------------------
STANDARD_INCLUDE_DIR
  Define this macro as a C string constant if you wish to override the standard
  choice of /usr/include as the default prefix to try when searching for header
  files.
------------------------------ clip ------------------------------------

 If an empty 'sys-include' is created for a cross-compiler and the '-v' used
to show the search order, these things will be seen, here shown with the
'arm-elf' target :

------------------------------ clip ------------------------------------
GNU CPP version 2.95.2 19991024 (release) (ARM/ELF non-Linux)
#include "..." search starts here:
#include <...> search starts here:
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\include
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\sys-include
 e:\usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\sys-include
 \usr\local\lib\gcc-lib\arm-elf\2_95.2\..\..\..\..\arm-elf\include
End of search list.
------------------------------ clip ------------------------------------

 The 'sys-include' will be searched before the 'include' but after the GCC's
own includes (and the fixed ones)...

 Of course the stardard headers being in the 'sys-include' makes the system
to 'work' too, but not in the way Stallman & Co. thought...

 Earlier it was important to run 'fixincludes' for the standard system 'non-ANSI
headers', but nowadays perhaps only the 3rd party ones need any checking. For the
newlib and glibc cases the obvious question is "What is wrong with the headers
in them, why they must be fixed while building GCC ?"

 So some cross targets may need header-fixing, but my opinion is that those
using newlib or glibc don't need it and the 'sys-include' must be left empty...
In any case I wouldn't trust the the things happening during 'fixincludes', but
would check the fixes done to the headers...

 The '--with-headers' copies the pointed headers into 'sys-include' for fixing,
so I'm against using it when the headers don't need any fixing... "Don't fix it,
if it ain't broken". Too often the GCC header-fixing has added bugs there weren't
before the fixing.

Cheers, Kai



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

RE: Building GCC as a cross compiler (target=sparc) on RedHat 6.2

[David Korn]

>-----Original Message-----
>From: Dan Alderman [ mailto:d.alderman@180sw.com ]
>Sent: 15 December 2000 17:50
>
>Hi,
>
>I've been using GCC on RedHat for some years now, and am begninning to
>delv into the realms of cross compilation....  Compiling GCC as a cross
>compiler is proving troublesome, can someone help please?

>I have sucessfully built binutils for the target platform
>(target=sparc-elf) and installed them into /export/usr/, and put
>/export/usr/bin at the beginning of my PATH.
>When trying to build gcc from a directory outside the source tree I get
>the following error after a few minutes of building...

>../../gcc-2.95.2/gcc/libgcc2.c:41: stdlib.h: No such file or directory
>../../gcc-2.95.2/gcc/libgcc2.c:42: unistd.h: No such file or directory
>make[3]: *** [libgcc2.a] Error 1
>make[3]: Leaving directory `/export/sources/build-gcc/gcc'
>make[2]: *** [stmp-multilib-sub] Error 2
>make[2]: Leaving directory `/export/sources/build-gcc/gcc'
>make[1]: *** [stmp-multilib] Error 1
>make[1]: Leaving directory `/export/sources/build-gcc/gcc'
>make: *** [all-gcc] Error 2
>
>Is there something I've missed?  I also tried to compile a cross gcc for
>the h8300-hitatchi-hms, but got the same errors.

 Yep. You missed providing the target headers where they can be found 
during the cross-compiler build. Drop them in $prefix/$target/sys-include
(or perhaps $prefix/$target/include ; there seems to be some disagreement
between different cross targets on this subject, but sys-include always
works for me) or add the flag --with-headers=/path/to/headers to your
configure command line.

       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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