I think even Sun recommends you use the GNU Assembler for x86_64 Solaris.

It seems (according to gcc -v) that GCC 4.2.1 re-configured itself to use:

/scratch/bfriesen/build/gcc-4.2.1/configure --program-suffix=-4.2.1 --enable-shared --enable-threads --enable-version-specific-runtime-libs --disable-nls --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=opteron --enable-languages=c,c++

so I just tried configuring with

/home/bfriesen/src/gnu/gcc-4.3.0/configure --program-suffix=-4.3.0 --enable-shared --enable-threads --enable-version-specific-runtime-libs --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=opteron --enable-languages=c,c++

and did get farther, but the final link fails like

/bin/bash /home/bfriesen/src/gnu/gcc-4.3.0/libgcc/../mkinstalldirs amd64
mkdir amd64
/home/bfriesen/build/gcc-4.3.0/./gcc/xgcc -B/home/bfriesen/build/gcc-4.3.0/./gcc/ -B/usr/local/i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-include -O2  -O2 -g -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc.map -o amd64/libgcc_s.so.1.tmp -g -fkeep-inline-functions -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f amd64/libgcc_s.so && if [ -f amd64/libgcc_s.so.1 ]; then mv -f amd64/libgcc_s.so.1 amd64/libgcc_s.so.1.backup; else true; fi && mv amd64/libgcc_s.so.1.tmp amd64/libgcc_s.so.1 && ln -s libgcc_s.so.1 amd64/libgcc_s.so
ld: fatal: unwind table: file /home/bfriesen/build/gcc-4.3.0/./gcc/amd64/crtend.o: section .eh_frame: bad cie version 0: offset 0xfffffd7fffdfb220

By using 'as' and 'ld' from binutils-2.18, I have achieved a successful compile.  Using gas and the system linker was not sufficient since it resulted in the same error.  Based on past experience, I don't have a lot of faith in GNU ld under Solaris.  Has it substantially improved?

The final configuration incantation is:
/home/bfriesen/src/gnu/gcc-4.3.0/configure --program-suffix=-4.3.0 --enable-shared --enable-threads --enable-version-specific-runtime-libs --with-gnu-as --with-as=/usr/local/lib/binutils-2.18/bin/as --with-ld=/usr/local/lib/binutils-2.18/bin/ld --enable-languages=c,c++

I always hear the opposite way around, that is the Sun's assembler and linker are not that good.

Any way, it is not gcc that fails here.

The previous GCC releases worked "out of the box" but 4.3.0 does not.  Give this, how can this bug report be "invalid"?  The configuration for Solaris 10 on x86 hardware has clearly degraded as compared to former releases.

http://gcc.gnu.org/install/specific.html#ix86-x-solaris210

It is recommended that you configure GCC to use the GNU assembler in /usr/sfw/bin/gas but the Sun linker, using the options --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld.

(In reply to comment #7)
> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
> 
> It is recommended that you configure GCC to use the GNU assembler in
> /usr/sfw/bin/gas but the Sun linker, using the options --with-gnu-as
> --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld.

It looks that the documentation needs to be updated.

A documentation update will be suffient provided that binutils 'ld' adequately supports Solaris now.  However, I notice that there are may be some issues with code built/linked with the Sun linker and the binutils linker.  In particular, a static-linked Perl interpreter fails to dynamically load its own modules if it is built using 4.3.0, but works with 4.2.1 (which uses Sun linker).  I am not sure why this is yet. Perhaps the needed symbols are not entirely resolved.

I will be doing more testing today.

*** Bug 36878 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> and did get farther, but the final link fails like
> ...
> ld: fatal: unwind table: file
> /home/bfriesen/build/gcc-4.3.0/./gcc/amd64/crtend.o: section .eh_frame: bad cie
> version 0: offset 0xfffffd7fffdfb220

I saw this, too with gcc-4.3.2 on Solaris 10 x86. The issue is described also in Bug 33100, which seems to be fixed in gcc-4.3.3. Furthermore, the linker error is supposed to be fixed with a Sun/Solaris patch: 139574-03 for SPARC and 139575-03 for x86 (quoted from Bug 33100).

-Marek

It seems that bugs gradually get fixed.  I am successfully using GCC 4.3.3 on the same system configure like:

/home/bfriesen/src/gnu/gcc-4.3.3/configure LDFLAGS='-L/usr/local/lib -R/usr/local/lib' --program-suffix=-4.3.3 --enable-shared --enable-threads --enable-version-specific-runtime-libs --with-gnu-as --with-as=/usr/local/lib/binutils-2.19/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu=opteron --enable-languages=c,c++,fortran

Notice that I am using 'as' from a recent binutils release rather than the one which comes with Solaris.

Unfortunately, GCC 4.4.0 is not so luckly since it once again does not work with Solaris ld.  If GCC does not work with Solaris ld, then I can't use it.

Bob

Since I have had successful builds of both 4.5.x and 4.6.x of gcc using current GNU binutils (2.20.1.x) and Sun ld, can this bug be closed?

(In reply to comment #13)
> Since I have had successful builds of both 4.5.x and 4.6.x of gcc using current
> GNU binutils (2.20.1.x) and Sun ld, can this bug be closed?

Yes, this bug can be closed.  I am using GCC 4.4.4 with GNU as and the Sun ld with no problems:

% gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /home/bfriesen/src/gnu/gcc-4.4.4/configure LDFLAGS='-L/usr/local/lib -R/usr/local/lib' --program-suffix=-4.4.4 --enable-shared --enable-threads --enable-version-specific-runtime-libs --with-gnu-as --with-as=/usr/local/lib/binutils-2.20/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-cpu=opteron --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.4 (GCC)

Bob