This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |