Re: Anyone built a 3.x cross compiler that runs under mingwin?

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

Paul Breed wrote:
> I'm currently building the m68k-elf 2.95.2 GCC under cygwin.
> Ideally I'd like to build a 3.x m68k-elf compiler under mingwin and 
> jettison all of the
> cygwin overhead.
>
> Has anyone done this?

 Yes, but not on Windoze, instead on Linux using Linux-x-MinGW
crosstools there. And the target really wasn't 'm68k-elf' but
'cpu32-elf', ie. the m68332/m68360 etc. with the CPU32-core
being the default...

> If so will you please share your build scripts?

 You mean the 'configure' and 'gcc/config.gcc' scripts or what ?
Why these standard scripts are not enough ?  (They weren't for me
as you saw -- adding the new 'cpu32' CPU required modifying the
'config.sub' and 'gcc/config.gcc' scripts).

 After building hundreds of cross-tools, I still don't need anything
else than some simple template 'scripts' for giving the 'configure'
and 'make' commands like:

AR=/usr/local/i386-mingw32/bin/ar \
CC=gcc-mingw32-3.2 \
CFLAGS=-Os \
CXXFLAGS=-Os \
NM=/usr/local/i386-mingw32/bin/nm \
RANLIB=/usr/local/i386-mingw32/bin/ranlib \
AR_FOR_BUILD=ar \
CC_FOR_BUILD=gcc-i486-linux-3.2 \
GCC_FOR_BUILD=gcc-i486-linux-3.2 \
NM_FOR_BUILD=nm \
RANLIB_FOR_BUILD=ranlib \
AR_FOR_TARGET=/usr/local/cpu32-elf/bin/ar \
CC_FOR_TARGET=gcc-cpu32-elf-3.2 \
GCC_FOR_TARGET=gcc-cpu32-elf-3.2 \
CXX_FOR_TARGET=g++-cpu32-elf-3.2 \
NM_FOR_TARGET=/usr/local/cpu32-elf/bin/nm \
RANLIB_FOR_TARGET=/usr/local/cpu32-elf/bin/ranlib \
../configure --build=i486-linux-gnu --host=i386-mingw32 \
--target=cpu32-elf --with-newlib
make all-gcc LANGUAGES="c c++ gcov proto"

because the Canadian cross requires standardized names like
'cpu32-elf-gcc' and my gcc-3.2.3 version of cpu32-elf target
GCC-name, 'gcc-cpu32-elf-3.2', doesn't fit into this. Neither
the other names.  So building binutils, GCC and GDB from
sources should require only running configure and make and
for these jobs nobody is expected to use any scripts (but
only me...)

 Generally if there are bugs which disable one building
the m68k-elf target toolchain with only 'configure' and
'make', they should be reported... I remember the 'crt0.o'
maybe still being present in the LIB_SPEC for 'm68k-coff/elf'
although the linker scripts should take care of this.

 Most bugs are easy to fix and I prefer to immediately set
some default target into every configuration (for the
m68k/cpu32-coff/elf I have the set the MVME162 board being
the default), so my builds go smoothly without any kind of
interrupts:

---------------------- clip -------------------------------
#undef INIT_SECTION_ASM_OP
#undef FINI_SECTION_ASM_OP

#undef LIB_SPEC
#define LIB_SPEC	""

#undef LIBGCC_SPEC
#define LIBGCC_SPEC	""

#undef LINK_SPEC
#define LINK_SPEC	""

#undef	STARTFILE_SPEC
#define STARTFILE_SPEC	"crtbegin.o%s"

#undef  ENDFILE_SPEC
#define ENDFILE_SPEC	"crtend.o%s -T mvme162.ld%s"

/* end of m68020-elf.h */
---------------------- clip -------------------------------

 Basically anyone trying to produce executables for 'm68k-elf'
shouldn't think any 'Arwen Undomiel's being real persons (but
maybe being the daughter of Steven Tyler), the 'elf' in the
name should hint something... What the 'arm-elf' then hints
("Arm the Earth Liberation Force", maybe?), but it targeting
to Angel (or Demon) may then equalize elves and angels :-)

 Ok, here the 'mvme162.ld' defines the default 'target system'
for produced executables. If this will be left away, it seems
to be critical where on the command line this option for the
linker will be given. It being last seems to work, like:

  m68k-elf-gcc -O2 -o hello.x hello.c \
    -Wl,-T,/usr/local/m68k-elf/lib/mvme162.ld

 Here the full path to the linker script must be given, the
'%s' in specs puts the GCC-driver to search for it.

 So a new 'm68k-elf' target toolchain cannot produce any
executables for some imaginary 'elf', one must set a default
'real' target into the 'specs' or  give it in CFLAGS for the
GCC-build or on the command line when trying the 'compiler'.

Cheers, Kai




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