Re: Trying to build a cross compiler from linux to netbsd...

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Dick Munroe wrote:
> 
> [root@linux egcs]# /home/egcs/gcc/xgcc -B/home/egcs/gcc/ -g -O2 foo.c
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: file not recognized:
> File format not recognized
> collect2: ld returned 1 exit status
> [root@linux egcs]# file /home/usr/local/i386-unknown-netbsd/lib/crt0.o
> /home/usr/local/i386-unknown-netbsd/lib/crt0.o: ELF 32-bit LSB
> relocatable, Intel 80386, version 1, not stripped

The version 1.5 of NetBSD seems to have switched to ELF from the earlier
a.out... A clip from the NetBSD/x86 FAQ at 'www.netbsd.org':

--------------------- clip ---------------------------------
Other sources of information

     XFree86 FAQ - for problems with installing or configuring X. 
     NetBSD 1.5 install notes - supported hardware and how to install. 
     The NetBSD ELF FAQ. As of NetBSD 1.5, the i386 port uses ELF instead
     of a.out.           ================================================
     =========
--------------------- clip ---------------------------------

The previous 1.4 version seems to have used aout in x86...

> which would seem a little weird since the cross compiler ought to
> know about the ELF stuff (or does EGCS 1.0.3 predate the ELF format?

 The egcs-1.0.3a knows only the 'aout' format for NetBSD...

> In which case I'll have to go back to an earlier version of the
> NetBSD release to get my libraries).

 Yes... The decision depends on which version the target machines are
running, it is expected that 1.4 binaries may have troubles when tried
under 1.3.2 machines, but not vice versa...
 
> Anyway, I'm trying for a.out format under NetBSD and clearly this
> isn't happening at the moment.
> 
> Any suggestions?

 Please check your current NetBSD binutils, they seem to be for aout
as the error hints and then they are ok... And your compiler is ok...
Just get the proper aout libs and headers for them and run, almost...

 If you look at the entry for NetBSD/x86 in 'gcc/configure' :

  i[3456]86-*-netbsd*)
	tm_file=i386/netbsd.h
	xm_file=i386/xm-netbsd.h
	# On NetBSD, the headers are already okay, except for math.h.
	fixincludes=fixinc.math
	tmake_file=t-netbsd
	;;

you will see that only the 'math.h' in the standard C headers needs any
fixing.. The patch for the 'math.h' follows (for NetBSD 1.3.2) :

---------------------- clip -----------------------
*** math.h.orig	Wed May 20 22:52:33 1998
--- math.h	Wed Jan  3 21:26:44 2001
***************
*** 65,71 ****
--- 65,75 ----
  #define _XOPEN_ fdlibm_xopen
  #define _POSIX_ fdlibm_posix
  
+ #ifdef __cplusplus
+ struct math_exception {
+ #else
  struct exception {
+ #endif
  	int type;
  	char *name;
  	double arg1;
***************
*** 151,157 ****
--- 155,165 ----
  extern double remainder __P((double, double));
  extern double scalb __P((double, double));
  
+ #ifdef __cplusplus
+ extern int matherr __P((struct math_exception *));
+ #else
  extern int matherr __P((struct exception *));
+ #endif
  
  /*
   * IEEE Test Vector

---------------------- clip -----------------------

 Perhaps this is already fixed in the 1.4 headers...

 I had built my earlier GCC for NetBSD (1.3.2) target in Oct. 1998, so
perhaps it was the time to tolerate the same pain again. And when my
disgust against using the '--with-headers=' was strong, I increased my
pain by using it now, copying the already installed standard netbsd-headers
into a temporary directory, disabling the '/usr/local/i486-netbsd/include',
where the headers were, by renaming it... Then configuring, building and
installing it (using 'make install') proved my thoughts to be true, the
target headers were copied into the

  /usr/local/i486-netbsd/sys-include

just as the docs said and they were left there even after the installation.
But no header-fixing happened during the build. So I had to manually install
the given patch for 'math.h'. It is very well known and identical for all
Sun and SVR systems...

 I used the same egcs-1.0.3a sources in question... Ok, the '-v' option of GCC
shows the potential problem, if it exists at all. For most people it is
enough that the cross-compiler works, for some like me, it also must work in
the right way :

----------------------------- clip -----------------------------------------
GNU CPP version egcs-2.90.29 980515 (egcs-1.0.3 release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/i486-netbsd/egcs-2.90.29/include
 /usr/local/i486-netbsd/sys-include
 /usr/local/i486-netbsd/include
End of search list.
----------------------------- clip -----------------------------------------

 As shown, the GCC's own and the fixed headers will be found first, then the
(local) system-specific headers and last the standard C headers for the target.
This has been the arrangement during the last ten or so years and I haven't seen
it being changed to anything else yet...

 The standard C headers being in the 'sys-include' just don't fit into this model...
So my suggestion would be to move everything from the 'sys-include' to the 'include'
and keep the 'sys-include' as the place for additional 3rd-party headers (like ones
with Oracle, other DB-systems, tcl/tk,....) not belonging to the 'standard C headers'...

 There was only one issue I fixed while building... Somehow the 'tm.h' had:

	#define TARGET_CPU_DEFAULT 1
	#include "i386/netbsd.h"

while the 'gcc/config/i386/netbsd.h' had another definition for TARGET_CPU_DEFAULT,
which then would have caused a redefinition warning with almost every file compiled...
So my fix to this was to remove the first row in 'tm.h'... Why it appeared there
remained unsolved, but who does care...

 The definition in 'gcc/config/i386/netbsd.h' could be checked :

----------------------- clip --------------------------------------
  #define TARGET_CPU_DEFAULT 0400		/* TARGET_NO_FANCY_MATH_387 */
  
  /* This is tested by i386gas.h.  */
----------------------- clip --------------------------------------

 The '0400' sounds more sane than '1', but checking what these 'TARGET' bits
mean from the 'gcc/config/i386/i386.h' could be recommended. BTW, the 0400
means that it is a octal number... Checking the sanity of the selection can be
left to you as homework, perhaps the more recent NetBSDs have a fixed math-
emulator and the 0400 isn't suitable any more. Or nobody runs 386-PCs or
486SX-PCs (without a 387) any more.  Ok, it is only the default setting and
rebuilding the GCC because of this doesn't sound necessary...

 The 'make install' also did some stupid things... I haven't used it for
years, but using my own install-script-templates which do all things just as
I wish...

 Ok, the following stupid things happened:

 1. the *protoize and gcov were copied with their base names into $prefix/bin

 2. the _G_config.h was copied into $prefix/$target/include

 3. the libiberty.a and libstdc++.a were copied into $prefix/$target/lib

 The things in 1. are target-dependent, and at least the libstdc++.a in 3. is
version dependent... Newer versions of _G_config.h and libiberty.a may probably
only add more things, but the new GCC can sometimes be older than the already
installed GCC(s)... My previous GCC for NetBSD was egcs-1.1. 

 So the right place for the _G_config.h and the libs is under the
'$prefix/lib/gcc-lib/$target/$version' (the header going to the 'include' there).
Renaming the '*protoize' and 'gcov' to have the same exec-prefix ('i386-netbsd-')
as 'gcc', 'g++' and 'c++' is also suggested...

 If you try later GCC versions for the same target, these things will not be
overwritten if you also remember to rename the 'gcc', 'g++' etc. to have a postfix
'-o' (meaning '-old', for instance 'i386-netbsd-gcc-o') or something before
installing the new GCC... The version dependent stuff should always be installed
into its own subdir ('$prefix/lib/gcc-lib/$target/$version').

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