Re: Cannont build cross-gcc for sh4

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

Alexander Gdalevich wrote:
> 
> I am trying to build crossgcc 3.0.3 on the win32/cygwin host for the Hitachi
> sh4 target.

 Not any possibility to use Linux or something more near 'real Unix' as the build
host ?  Keeping and needing one's car in garage and on the road doesn't mean that
the car must always be built and fixed in the garage or on the road... There may
be other places more suitable to these jobs...

 For instance:

 ./configure --build=i686-linux-gnu --host=i686-cygwin --target=sh-elf

 Of course the 'i686-linux-gnu-x-i686-cygwin' and 'i686-linux-gnu-x-sh-elf' cross-
tools are the prerequisities, to produce the Cygwin binaries on Linux and to produce
'she-elf' objects (for the target libs) on Linux.  Producing even the 'libgcc.a's
again is considered to be vain (12 pcs), so the need to reproduce them is clearly
a bug... Perhaps there is a '-disable-libgcc' option for configure and using the
'make all-gcc' then really produces only the GCC for the secondary host...  

 Anyway the 1st (native) host is the most time-consuming, I would put the machine
building the compiler and all the 12 library variations during night, at least
when using a slow under-500 MHz PC... Some messages have claimed that Windoze with
Cygwin can be 4-6 times slower than Linux in builds, so a 4-hour build on Linux
may need 16 - 24 hours on Windoze. All the bosses preferring Windoze as the build
system, grab the productivities from this...

 I have always wondered the policy of RedHat in this issue, instead of maintaining
a pre-built toolset for producing Windoze/Cygwin stuff on their Linux, they try to
convince people that a Windoze with Cygwin is the better platform and the better
'Unix' for building GNU stuff for Windoze. Of course it should be a piece of cake
to build a Linux-x-Cygwin cross-toolkit, but at least the binutils have been a
continous nuisance, only some specific versions have worked for the Win32 targets.
So a prebuilt toolset for RedHat 6.2 (should work on 7.x too...) wouldn't be a bad
idea...

 Of course the conversion of Windoze into Unix would then be vain, if one has Linux,
so a more minimal runtime for the produced executables would be enough and using
Mingw as the Win32-runtime host would be another possible choice...

 Anyway building a 'sh-elf' toolchain for Linux and Mingw hosts hasn't shown any
problems like described here...
 
> In either case build fails apparently when xgcc tries to build libgcc.
> The errors are:
> In file included from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/elfos.h:36,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/svr4.h:46,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/sh/elf.h:48,
>                  from tm.h:4,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/sh/xm-sh.h:34,
>                  from tconfig.h:3,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/elfos.h:36,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/svr4.h:46,
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/sh/elf.h:48,
>                  from tm.h:4,
> 
> the last few lines repeat over and over sometimes being interrupted by
> 
>                  from
> /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/config/sh/xm-sh.h:34,
>                  from tconfig.h:3,
>                  from /cygdrive/d/tmp/gcc_srcdir/gcc-3.0.3/gcc/libgcc2.c:36:
> tconfig.h:2:24: #include nested too deeply

 So I would blame the Windoze/Cygwin...  There is a maillist about problems
with the Cygwin environment and my opinion is that too much "Cygwin doesn't
work as Unix"-problems have been presented here, perhaps because the problems
came when trying to use Cygwin as the build host...

 There are real problems with the 'sh-elf' target and gcc-3.0.x and talking
about them would be more on-topic... For instance:

 What is the 'target' now for 'sh-elf' ?  Definitely it is not an embedded
SH-board using newlib any more. The new config settings assume the target
possibly using shared libs and its C-library having something equal with
the '__eabi()' in PowerPC, a totally unknown initialization routine named
'setup_vararg_and_call_main', called from the new 'crt1.o' startup for
'sh-elf'... Editing the resulted 'specs' and putting the 'crt0.o' from
newlib there however puts the toolchain to work again, at least while
building...

 Whoever added the new 'crt1.asm', 'crti.asm' and 'crtn.asm' startups and
put the 'sh-elf' configuration to use them, could have added a short comment
about their purpose into the 'gcc/config/sh/elf.h' or the '.../crt1.asm'.
It is totally unnecessary to add new problems without any clear solutions.

 The 'sh-linux-gnu' is another ELF-using target, no 'sh-sysv4' AFAIK, but
perhaps the 'sh-elf' is now a fake name for 'sh-ecos' (the RedHat's embedded
RTOS) or 'sh-elix' (the RedHat's embedded Linux). Or something... But I would
prefer people using names from the real world for things, not elves, trolls,
orcs, dwarfs or something to describe RTOS'es or Linux-OS'es... Perhaps the
'crt1.o' is a bug in the 'sh-elf' configuration, perhaps Sun is now preparing
a Solaris2/SH, if one remembers the 'powerpc-elf' case... Solaris2's have
their 'crt1.o', 'crti.o' and 'crtn.o' sources at least in the 'sparc' and
'i386' config dirs...

 Hmmm, another reply took the 'sh-linux-gnu' case into this and suggested
adding Linux-patches... Looked at those, but didn't see any 'sh-elf' (fixes
for the plain vanilla pure ELF) stuff there, only all kind of hacks for the
Linux/SH... Not even a fix for the mess with :

  int pragma_interrupt;
  int interrupt_handler;
  int current_function_interrupt;

(please choose your favourite...) basically all meaning the same thing (the
'current' function is an ISR), and all these used in the code... Like the
Highlander with his Japanese-made sword, I would say "There could be only
one" and do something radical... Ok, I have 'only one' in my gcc-3.0.3
sources, just guess which one survived...

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