Re: m68k cross-compiler

["Bill Randle" <billr at exgate dot tek dot com>]

Jim,

I recently went thru this same process and am now using my Linux laptop
as my primary development system (it's faster than the SS-20 running
Solaris 2.5.1).

A couple of comments:
  1. I may be wrong here, but I seem to recall some previous messages
     on this list regarding difficulty building a cross-compiler with
     2.95. Earlier versions (e.g. 2.8 and before) were easier to build.

  2. You may want to build your tools with a target of "m68k-wrs-vxworks",
     rather than "m68k-aout" (don't know how much difference it makes).

  3. [Most important, I think]: If you're building for a VxWorks target,
     you don't need 'newlib' as VxWorks includes the necessary C library
     functions. Now there may be some incompatabilities between the
     VxWorks C library and gcc-2.95 - I'm not sure here. Unless you
     specifically need some functionality present in 2.95, my suggestion
     would be to use 2.8.1 or 2.7.2.1. I used 2.7.2.1 because that's
     what we are using  on Solaris and I wanted to ensure that the
     generated code on both systems would be identical.

FWIW, here's my setup (VxWorks 5.2):
	/src/binutils-2.7/
	/src/gcc-2.7.2.1/
	/src/gcc-2.7.2.1/m68k-wrs-vxworks-linux/  <-- build dir for linux
	/src/gcc-2.7.2.1/m68k-wrs-vxworks-solaris2/ <-- build dir for Slowaris
	/src/libg++-2.7.2/
	/src/libg++-2.7.2/m68k-wrs-vxworks-linux/ <-- build dir for linux
	/usr/vx5.2/  <-- VxWorks distribution tree
	/usr/vx5.2/i386-linux/  <-- linux cross tools
	/usr/vx5.2/bin/  <-- symlinks into execs in ../i386-linux/bin
	/usr/vx5.2/h/  <-- VxWorks header files
	/usr/vx5.2/lib/  <-- VxWorks libraries

The directory layout mirrors the way WRS did things with VxWorks 5.2 (and
earlier). Tornado (VxWorks 5.3+) has a slightly different layout.

And the configs:
  For binutils:
  % more binutils-2.7/config.status
  ./configure --host=i686-unknown-linux --prefix=/usr/vx5.2/i386-linux \
	--program-suffix=68k --target=m68k-wrs-vxworks --with-gnu-as \
	--with-gnu-ld

  For gcc:
  % more gcc-2.7.2.1/m68k-wrs-vxworks-linux/config.status
  ../configure --target=m68k-wrs-vxworks --with-gnu-ld --program-suffix=68k \
	--prefix=/usr/vx5.2/i386-linux --local-prefix=/usr/vx5.2/i386-linux \
	--enable-languages="c c++"
  (Because the configure script didn't recognize i686-xxx, I had to edit
   the config.guess file and replace occurances of "i[345]86" with
   "i[3456]86".)

  I then edited the generated Makefile and added "-I/usr/vx5.2/h" to the
  definition of GCC_FOR_TARGET to force it to find the VxWorks header files
  and ran 'make', 'make install'.

  So far, I've had no problems building our 1.5MB target rom image.

	-Bill Randle
	Tektronix, Inc.
	billr@exgate.tek.com

On Jan 5,  8:35am, Jim Benson wrote:
} Subject: m68k cross-compiler
}
}   I (a new-be to compiling compilers and cross-compilers) have been working
} on compiling a cross-compiler to run on a linux x86 machine and to compile
} m68k code which can be loaded into embedded 680xx cpus running  vxWorks.
} My goal is to replace the wind-river supplied compiler (gcc version
} 2.6-95q2) than runs on a SunOS 5.4 host with a more up-to-date
} cross-compiler (e.g. gcc-2.95.2) that will run on linux machines
} and create obj code for 68040 and 68060 cpus.
}
}
} I successfully compiled
} gcc-2.95.2 as a native compiler under linux
} (Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
} gcc version 2.95.2 19991024 (release)).
}
} I then compiled gcc as a cross-compiler for a.out object
} code for m68k. My steps to create the cross-compiler were:
}
} 1.)The gcc source was already in: /usr/local/gcc-2.95.2
}
} 2.) in usr/local/gcc-2.95.2 i Untarred binutils-2.9.5.0.22.tar and
}     newlib-1.8.2 into gcc-2.95.2
}
} 3.) made dir /usr/local/m68k-aout
}
} 4.) in gcc-2.95.2 i made the link: ln -s newlib-1.8.2/newlib newlib
}
} 5.) from newlib: cp -d -p -r -v newlib/libc/include /usr/local/m68k-aout
}
} 6.) mkdir /usr/local/m68k-aout-builddir
}
} 7.) vi envStuff to read:
}     host=i686-pc-linux-gnu
} 	target=m68k-aout
} 	prefix=/usr/local
}
} 8.) source envStuff
}
} 9.) in -builddir:
}     ../gcc-2.95.2/binutils-2.9.5.0.22/configure --target=$target
}     --prefix=$prefix --enable-languages=c++ -v
}
} 	make all
} 	make install
}
} 10.) in -builddir:
}     ../gcc-2.95.2/configure --target=$target
}     --prefix=$prefix --enable-languages=c++ --with-newlib -v
}
}         make all
}         make install
}
} 11.) in -builddir:
}     ../gcc-2.95.2/newlib-1.8.2/configure --target=$target
}     --prefix=$prefix --enable-languages=c++  -v
}
}         make all
}         make install
}
} These steps resulted in success in the sense that i could compile
} a "hello world" toy, load it (via the vxWorks dynamic linker...ld <
} test.o) into the m68k running vxWorks and upon typing the function
} into the vxWorks shell prompt...get the expected results.
}
} However, after successfully compiling a real world application and
} loading it via: ld < real.o
} (where real.o is obtained via: m68k-aout-ld -o real.o -r app1.o app2.o
} ...) i received the following errors from the vxWorks host prompt:
}
} undefined symbol: ___rtti_user
} undefined symbol: ___rtti_si
} undefined symbol: _terminate__Fv
}
} Of course the code compiles and links (on the vxWorks m68k embedded cpu)
} fine on solaris host with the wind-river supplied compiler.
}
} A search of the gcc mail archives for rtti_user revealed 1 partially
} useful message dated 19-oct 1999 having to do with ___rtti_user showing up
} under nm of s***as "U" (as it does in my case) rather than and "T" as it
} is stated as it should.  I could not find the complete resolution of the
} problem in the archives.
}-- End of excerpt from Jim Benson



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