Re: crosscompiler x86->solaris2.8 problems

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

Spencer Marshall wrote:
> 
> I have read the pages of Per Fransson and those in this mailing list
> regarding crosscompiler, but unfortunately, none fix my problem.

 I remember the issue remaining still unsolved... Solving it needs the builders
(you and Per) checking some things...

> and get the errors shown below
> 
> /export/dalmany/gdsm/build-gcc\
> /sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/ctype_noninline.h:
> `_ctype_' undeclared (first use this function)

 From where this header was symlinked ?  It SHOULD be symlinked from the source directory:

    $src/libstdc++-v3/config/os/solaris/solaris2.7/bits

into this build directory. If not, but from somewhere else, the workaround of course is to
manually rearrange the symlinks by using 'ln -f -s' for the right source stuff and so get
the right stuff into use. The 'ctype.h' in newlib defines the '_ctype_', while the one in
the Solaris2 doesn't, so it seems like the 'newlib'-stuff was symlinked for Solaris2.8...

 It may be that editing the:
  /export/dalmany/gdsm/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/config.status
by replacing 'newlib' with 'solaris/solaris2.7' in the lines defining the 'os/<system>/bits'
directory used, and then trying 'make' again, the 'libstdc++-v3'-stuff would be reconfigured
and the build could succeed, but I'm not sure... Probably the symlinks will not be fixed.

 The reason WHY the wrong stuff was taken into use may be harder to track, but using some
'verbose'-mode for 'configure' and looking at the logfile, the reason may be found. Anyway
this is a bug and needs a bug report to 'gcc-bug@gnu.org' or what it then was...

 So the cure should be that the right stuff from
   $source/libstdc++-v3/config/os/solaris/solaris2.7/bits
should be symlinked into the    $build/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits
and why this didn't happen during the configuring is the bug to report and to solve, but just
manually fixing this issue is one workaround...

Cheers, Kai

PS. With the Solaris2.7 target I hadn't this problem, or simply don't remember having it, but
if my gcc-3.0.x version now is 3.0.1, 3.0.2 or 3.0.3, updating to 3.0.4 would tell what the
case is...



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