Re: Help with newlib on cygwin

["Kai Ruottu" <karuottu at mbnet dot fi>]

Dan Kegel <dank@kegel.com> wrote:

> Liuzhao wrote:
> > I am having problems building gcc-3.3.1 on cygwin for Hitachi CPU 
> > sh series.
> > binutils-2.13.1
> > gcc-3.2.1
> > newlib-1.10.0
> > ...
> > newlib/libm/math/er_lgamma.c: In function `__ieee754_lgamma_r':
> > newlib/libm/math/er_lgamma.c:309:  
> > internal error: Segmentation fault
> 
> You may need a few patches for gcc.  See
> http://kegel.com/crosstool/current/patches/gcc-3.3.1/
> (each patch begins with a description of what it fixes)
> or perhaps try gcc-3.3.2.

 Maybe the target-specific patches aren't enough when the
binaries produced for the host are crashing... Here my
suspects are pointed to the Cygwin host. Someone recently
also had problems with 'arm-elf' toolchain binaries crashing
on Cygwin host, I remember some Dane from some some
thermostate company (Danfoss ?) doing this, but they then
should have devices with which to cool down ;-).

 I have gcc-3.3.1 built for 'sh-elf' on Linux/x86 host and then
newlib-1.11.0 built with it. Nothing in these builds did crash.
So the plain vanilla sources should work but of course there
can be bugs and these should be fixed if one is going to do
some serious work with the tools, not only learning how to
build stuff, what anyone with a email address ending with
'.edu(.cn)' could simply do...

 Using the current newlib release ('1.11.0') could be suggested,
why the old '1.10.0' was chosen is weird...  Why the old binutils,
'2.13.1' ?   And was the '3.2.1' or the '3.3.1' a typo?  Is it really
so hard to be precise in the version numbers and to use the
current release sources instead of one or two years old ones
with bugs everyone has already almost forgotten there once
being?

 If the case is about serious work with the tools, there maybe
isn't much sanity in the 'build it yourself' approach when there
are companies like KPIT which give free support for the Hitachi
tools, for SH and H8/300, and have workers to hunt bugs in the
tools as their full-day job.  The Windoze-hosted toolchains are
freely downloadable and are MinGW-hosted AFAIK, so their
stability is dependent on the MS-provided runtimes like MSVCRT.DLL,
not on the stability of the Cygwin layer.

 In the 'learning how to build' case a very good result could be
that one reports that Cygwin is buggy and so disables one to
build the tools, but the same job tried on Linux succeeds...
And maybe one can try to build the Cygwin-hosted tools on Linux
(like RedHat does with the Cygwin releases) but the crashes then
will appear delayed at runtime, not already in the build stage.

 Trying to build old sources with up-to-date tools can also be a very
good way to get into serious troubles, those old sources tend to
have workarounds for old bugs in some old tools but the new tools
don't have the old bugs, so the old workarounds for the unexisting
bugs then provide quite many bugs...
  
 Anyway in this case I would download a KPIT-produced (patched)
gcc-3.3.x and use it as a reference toolchain. If it doesn't crash
when building newlib with it, then there is something rotten in the
own Cygwin-hosted toolchain, or on Cygwin itself maybe...  The
'http://www.kpit.com' (KPIT is in India, in the neirboughood of China)
should lead to their Hitachi tools...

Cheers, Kai

PS.  For the 'arm-elf' target on Windoze/Cygwin problem :
"Andras Tantos" <andras_tantos@tantos.yahoo.com> recently wrote
on the 'gnu.gcc.help' NG :

"I have a problem with generating binary images for an embedded ARM
processor using GCC 3.3.1 as a cross compiler hosted under MinGW.
The generated images are larger than required and I suspect the root of
the problem is that the linker links in all the functions defined in the
C/C++ files even if there's no reference to them. (i.e. it will link in the
whole .o file if there's a single reference to something in that object.)  I
thought that modern object formats (ELF, COFF) has a solution for this
problem. I've tried both arm-elf and arm-pe targets but had the same
result (I wasn't able to create a functional arm-coff cross-compiler)." 

Ok, the problem here itself isn't important but that there are already built
tools which someone could send to serve as reference tools for the
self-built ones... For 'arm-elf' there have been downloadable tools but
usually they have been Cygwin-hosted, not as native Windows apps
(MinGW-hosted). Maybe the 'www.ocdemon.com' etc. have now
changed the chosen host, who knows...


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