I desire to replace my OS's gcc toolchain with a newer version since the one supplied by the manufacturer is a little old (and missing some languages). I am compiling gcc-4.2.1 (release from ftp://mirrors.kernel.org/gnu/). Sun's gcc (not used during build): # gcc -v Reading specs from /user/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds/sfwnv-86/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) Linker used during build: # /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.622 GCC used to build (From BlastWave): # gcc -v Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs Target: i386-pc-solaris2.8 Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.2 Failing configure command: /opt/gcc-4.2.1/configure --build=i386-pc-solaris2.11 --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared --enable-threads=posix --enable-libada --enable-libssp --enable-libmudflap --enable-libgomp --enable-decimal-float --with-x --x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-gconf-peer --with-stabs --enable-stage1-checking=release --enable-multilib --enable-nls --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-xmlj The reason I am using the "--without-gnu-ld --with-ld=/usr/ccs/bin/ld" option is because the Solaris OS supplied gcc (configured by SUN) (and other gcc's such as BlastWave's) all seem to use it. It seems reasonable to follow the manufacturers advice if you are going to replace the OS's system compiler. It may well be true (or not) that _after_ I successfully build a newer gcc that I should compile a newer binutils and use that -- but building the newer gcc with the 'recommended' linker is what I desire to do (for now). If I configure without "--enable-xmlj" the build (or if you prefer Sun's ld) works. If I configure using "--enable-xmlj" I get a relocation error in gnu-xml concerning debug_info (so it seems we could fix one small section and get everything to work). Here is a portion of my build log: # grep -B 10 -A 2 LASF7986 /opt/gcc-4.2.1-build-1/made_1j_log.txt mkdir .libs/libgcj.lax/libffi_convenience.a (cd .libs/libgcj.lax/libffi_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../libffi/.libs/libffi_convenience.a) rm -fr .libs/libgcj.lax/libzgcj_convenience.a mkdir .libs/libgcj.lax/libzgcj_convenience.a (cd .libs/libgcj.lax/libzgcj_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../zlib/.libs/libzgcj_convenience.a) rm -fr .libs/libgcj.lax/libgcjgc_convenience.a mkdir .libs/libgcj.lax/libgcjgc_convenience.a (cd .libs/libgcj.lax/libgcjgc_convenience.a && /usr/sfw/i386-pc-solaris2.11/bin/ar x /opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava/../boehm-gc/.libs/libgcjgc_convenience.a) /opt/gcc-4.2.1-build/./gcc/xgcc -shared-libgcc (HUGE command deleted) /i386-pc-solaris2.11/../../../i386-pc-solaris2.11/lib -L/usr/sfw/lib/gcc/i386-pc-solaris2.11/../.. -lgcc_s -lgcc_s -lc /opt/gcc-4.2.1-build/./gcc/crtend.o /usr/lib/crtn.o -Wl,-h -Wl,libgcj.so.8 -o .libs/libgcj.so.8.0.0 ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7985: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7986: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7987: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF40: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored (The errors continue for over 20000 lines, finally ending with this:) /i386-pc-solaris2.11/../../../i386-pc-solaris2.11/lib -L/usr/sfw/lib/gcc/i386-pc-solaris2.11/../.. -lgcc_s -lgcc_s -lc /opt/gcc-4.2.1-build/./gcc/crtend.o /usr/lib/crtn.o -Wl,-h -Wl,libgcj.so.8 -o .libs/libgcj.so.8.0.0 ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7985: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7986: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF7987: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored ld: warning: relocation error: R_386_32: file .libs/gnu-xml.o: symbol .LASF40: external symbolic relocation against non-allocatable section .debug_info; cannot be processed at runtime: relocation ignored If there is no desire to fix gnu-xml so it would not fault Sun's linker then can we check the linker version in the root configure script and disallow --enable-xmlj so that the build of gcc does not work perfectly for several hours and then fail when the build is just about to complete :(! .
Correction: The "finally ending with this" section should read: --- .LPR2 0x123aa1 .libs/gnu-xml.o .LPR2 0x123ba1 .libs/gnu-xml.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[3]: *** [libgcj.la] Error 1 make[3]: Leaving directory `/opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/gcc-4.2.1-build/i386-pc-solaris2.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/opt/gcc-4.2.1-build' make: *** [all] Error 2 ---
Test results are here: Results for 4.2.1 testsuite on i386-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg02160.html Everything passed (and failed) as expected for this version of gcc when configured with these options on Cygwin (under WinXP) or Debian/GNU. A (very?) good result for a first attempt at porting to my new OS. Even got a few passes with mudflaps -- but I'll see if I can fix that up.
I don't understand the last comment. Do you still have a bug to report? If no, then please close this, if yes, then please state what is different from the successful build you used to obtain the test results. Anyway, if you have the relocation issue still, it'd be interesting to see cd i386-pc-solaris2.11/libjava ./libtool --tag=CXX --config ./libtool --tag=GCJ --config to exclude a bogus pic_flag setting.
>> I don't understand the last comment. Do you still have a bug to report? Yes. >>If no, then please close this, if yes, then please state what is different >>from the successful build you used to obtain the test results. The successful build is the result NOT configuring with "--with-xmlj" When I build I submit the test results to help the community. The test results posted show that the numbers of FAILs is similar to other platforms, thus it is a "successful" build (but without "--with-xmlj" which I would add if it did not block the build). The number of PASSes for the C compiler is very high and this version of GCC (4.2.1) is one of the higher 4.2.x series that can be built. There are other bug reports here by other people who were unable to build other 4.2.x versions on OpenSolaris. I hope I have explained the significance of my post adequately. Blows own horn. This is a milestone for the month old operating system. I am not expert enough in Java to be the one who would fix this for us all. Even if I was I would be opening this report to post the fix. Please do not close this bug unless it is either: 1. Fixed. 2. Decided it will not be fixed. >>Anyway, if you have the relocation issue still, it'd be interesting to see >> cd i386-pc-solaris2.11/libjava >> ./libtool --tag=CXX --config >> ./libtool --tag=GCJ --config >>to exclude a bogus pic_flag setting. Here they are (from a successful build, no "--with-xmlj"):
Created attachment 15826 [details] ./libtool --tag=CXX --config > tag_CXX.txt
Created attachment 15827 [details] ./libtool --tag=GCJ --config > tag_GCJ.txt Attached two outputs from libtool
Added "Known to work" 4.4.0 (gcc version 4.4.0 20090126 (experimental) [trunk revision 143680]). Tested on OpenSolaris 2008.11 i386-pc-solaris2.11 and Fedora 10 i386-redhat-linux-gnu . Rob
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.