Re: crosscompiler x86->solaris2.8 problems

[Corrado Giacomini <Corrado dot Giacomini at trema dot com>]

I tried to build gcc3.0.4 after having changed

build-gcc/sparc-sun-solaris2.8/libstdc++-v3/config.status

and I worked fine.

I also had a look into the configuration files to find out why things 
are not correctly build
I and I see than the file
gcc-3.0.4/libstdc++-v3/configure  
set
os_include_dir="config/os/newlib for any target that is not "*-linux*"

so I just copied all lines of the default case "*"  and I created a new 
case with "*-solaris*"
And every thing is now compiling.  
I am not very familiar with autoconf may be there is a cleaner way to 
fix it.
Has someone reported this to GCC mailing list ?

I also tried to compile gcc2.95.3... things are build in a slidely 
different way
but I don't have this problem I am facing with gcc3.0.4

-Corrado

Kai Ruottu wrote:

>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
>
>




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