building gcc 4.0.0 on Solaris

building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

I'm attempting to build gcc 4.0.0 on Solaris. I have been unable to 
build gcc or at least some of its components since the release of gcc 3.4.

Here are a few details on my system:
  - Solaris 8 7/01
  - Sun's as/ld
    as: Sun WorkShop 6 99/08/18
    ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.286
  - GNU binutils 2.15

I've tried two approaches.


1) Using Sun's as/ld. I build gcc this way:
    	cd /tmp
    	gtar xjf ~/gcc-4.0.0.tar.bz2
    	mkdir gcc
    	cd gcc
    	setenv CONFIG_SHELL /bin/ksh
    	/tmp/gcc-4.0.0/configure \
    		--prefix=/usr/local/gcc-4.0.0
    	gmake bootstrap

The build fails with the following message:
ld: fatal: relocation error: R_SPARC_DISP32:
file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
symbol <unknown>: offset 0xfccd33ad is non-aligned

I've searched Google for this error and came across similar error 
messages without finding a solution:
http://gcc.gnu.org/ml/gcc-prs/2003-03/msg00497.html

Any clues?



2) Using GNU binutils. I build gcc this way:
    	cd /tmp
    	gtar xjf ~/gcc-4.0.0.tar.bz2
    	mkdir gcc
    	cd gcc
    	setenv CONFIG_SHELL /bin/ksh
    	/tmp/gcc-4.0.0/configure \
    		--prefix=/usr/local/gcc-4.0.0 \
    		--with-as=/usr/local/binutils/bin/as \
    		--with-ld=/usr/local/binutils/bin/ld
    	gmake bootstrap

The build fails while compiling the Java libraries with gcj. No error 
message appears because the oputput of gcj is discarded by the build 
system. Running the last command line manually, I get the following 
error message:
/tmp/GCC/gcc/gcj [...] -o java/lang/StrictMath.o
/tmp/ccMGENqa.s: Assembler messages:
/tmp/ccMGENqa.s:10374: Error: Illegal operands:
There are only 32 single precision f registers; [0-31]

I've found out this is a known issue with the current GNU binutils 
package. See for example:
http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-March/002879.html
As far as I can understand, it's not possible to build gcc 4.0.0 and gcc 
3.4.* using GNU binutils with current release 2.15 of GNU binutils. One 
has to use the CVS sources or at least one file.

Would it be possible to document this requirement in the platform pages?
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2



Speaking of the sparc-sun-solaris2* platform, I read:
	GCC 3.4 changed the default debugging format from STABS
	to DWARF-2 for 32-bit code on Solaris 7 and later. If you
	are using the Sun assembler, this change apparently runs
	afoul of Sun bug 4910101, for which (as of 2004-05-23)
	there is no fix. A symptom of the problem is that you
	cannot compile C++ programs like groff 1.19.1 without
	getting messages similar to the following:
	ld: warning: relocation error: R_SPARC_UA32: ...
	  external symbolic relocation against non-allocatable
	  section
	  .debug_info cannot be processed at runtime:
	  relocation ignored.
	To work around this problem, compile with -gstabs+
	instead of plain -g

I had a look at Sun Online Support and found:
	Bug ID: 4910101
	Synopsis: fbe needs a way to reference section labels
	Category: compiler
	Subcategory: assembler-x86
	Description:
	The bug was first found with the -misalign flag, but the
	real bug is because the code is being passed through the
	assembler.
	Integrated in releases: k2_dev
	Summary: fbe needs a way to reference section labels

Therefore :
1) This seems to be x86-specific, so I would suggest moving this 
paragraph from sparc-sun-solaris2* to i?86-*-solaris2*
2) It looks like there is a fix, however I don't know what k2_dev is, 
maybe this is an internal development version and the fix has not been 
relesed yet.

--
Dimitri Papadopoulos

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> 1) Using Sun's as/ld. I build gcc this way:
>     	cd /tmp
>     	gtar xjf ~/gcc-4.0.0.tar.bz2
>     	mkdir gcc
>     	cd gcc
>     	setenv CONFIG_SHELL /bin/ksh
>     	/tmp/gcc-4.0.0/configure \
>     		--prefix=/usr/local/gcc-4.0.0
>     	gmake bootstrap
>
> The build fails with the following message:
> ld: fatal: relocation error: R_SPARC_DISP32:
> file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
> symbol <unknown>: offset 0xfccd33ad is non-aligned

Probably a Sun 'as' bug, a similar problem was reported on Solaris 7:
http://gcc.gnu.org/install/specific.html

GCC 4.0.0 is known to bootstrap on Solaris 8 with:
as: Sun WorkShop 6 03/08/05 Compiler Common 6.0 Patch 114802-01
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.285

> Would it be possible to document this requirement in the platform pages?
> http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2

It is already documented in *-*-solaris2* that 2.15 is broken on the platform.

> Speaking of the sparc-sun-solaris2* platform, I read:
> 	GCC 3.4 changed the default debugging format from STABS
> 	to DWARF-2 for 32-bit code on Solaris 7 and later. If you
> 	are using the Sun assembler, this change apparently runs
> 	afoul of Sun bug 4910101, for which (as of 2004-05-23)
> 	there is no fix. A symptom of the problem is that you
> 	cannot compile C++ programs like groff 1.19.1 without
> 	getting messages similar to the following:
> 	ld: warning: relocation error: R_SPARC_UA32: ...
> 	  external symbolic relocation against non-allocatable
> 	  section
> 	  .debug_info cannot be processed at runtime:
> 	  relocation ignored.
> 	To work around this problem, compile with -gstabs+
> 	instead of plain -g
>
> I had a look at Sun Online Support and found:
> 	Bug ID: 4910101
> 	Synopsis: fbe needs a way to reference section labels
> 	Category: compiler
> 	Subcategory: assembler-x86
> 	Description:
> 	The bug was first found with the -misalign flag, but the
> 	real bug is because the code is being passed through the
> 	assembler.
> 	Integrated in releases: k2_dev
> 	Summary: fbe needs a way to reference section labels
>
> Therefore :
> 1) This seems to be x86-specific, so I would suggest moving this
> paragraph from sparc-sun-solaris2* to i?86-*-solaris2*

The problem is present on SPARC so the paragraph can't be moved.
Not sure whether the bug ID is correct though.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

>>The build fails with the following message:
>>ld: fatal: relocation error: R_SPARC_DISP32:
>>file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
>>symbol <unknown>: offset 0xfccd33ad is non-aligned
> 
> 
> Probably a Sun 'as' bug, a similar problem was reported on Solaris 7:
> http://gcc.gnu.org/install/specific.html
> 
> GCC 4.0.0 is known to bootstrap on Solaris 8 with:
> as: Sun WorkShop 6 03/08/05 Compiler Common 6.0 Patch 114802-01
> ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.285

OK, I guess the latest compilers from Sun ship with a better "as".
Unfortunately I'm stuck with Sun Studio One 7 for now. Maybe it should
be documented that a recent version of "as" is needed by gcc.


>>Would it be possible to document this requirement in the platform pages?
>>http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
> 
> 
> It is already documented in *-*-solaris2* that 2.15 is broken on the platform.

Oh, I don't know how I missed that, sorry. I guess I was looking for the
error message, not for the solution.


>>Therefore :
>>1) This seems to be x86-specific, so I would suggest moving this
>>paragraph from sparc-sun-solaris2* to i?86-*-solaris2*
> 
> 
> The problem is present on SPARC so the paragraph can't be moved.
> Not sure whether the bug ID is correct though.

Maybe I'm misunderstanding something, but it looks like either the
problem is not present on SPARC, or the comment is wrong: patch 4910101
is for x86 platforms only.

In any case this looks wrong and needs to be fixed.

--
Dimitri Papadopoulos

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> OK, I guess the latest compilers from Sun ship with a better "as".
> Unfortunately I'm stuck with Sun Studio One 7 for now. Maybe it should
> be documented that a recent version of "as" is needed by gcc.

A version not affected by the bug.  4.0.0 bootstraps on Solaris 2.5.1 with
as: WorkShop Compilers 4.2 dev 13 May 1996

It looks like we need to document that as: Sun WorkShop 6 99/08/18 is 
problematic.

> Maybe I'm misunderstanding something, but it looks like either the
> problem is not present on SPARC, or the comment is wrong: patch 4910101
> is for x86 platforms only.

The problem is definitely present on SPARC (see the relocation).

> In any case this looks wrong and needs to be fixed.

Yes, we should probably revisit the problem.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[James E Wilson]

Dimitri Papadopoulos-Orfanos wrote:
> As far as I can understand, it's not possible to build gcc 4.0.0 and gcc 
> 3.4.* using GNU binutils with current release 2.15 of GNU binutils. One 
> has to use the CVS sources or at least one file.

FYI binutils-2.16 has just been released.  You might want to try that.

Not clear if there will be a binutils-2.15.1 release, but if you check 
out the binutils-2_15-release tree from sourceware.org cvs, then it 
includes the patch that you need.  It was added to the release branch 
after the binutils 2.15 release was made.

>     Bug ID: 4910101
>     Synopsis: fbe needs a way to reference section labels
>     Category: compiler
>     Subcategory: assembler-x86

Apparently this problem only shows up for x86 when using Sun tools, but 
when using GNU tools, it also shows up for sparc.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> >     Bug ID: 4910101
> >     Synopsis: fbe needs a way to reference section labels
> >     Category: compiler
> >     Subcategory: assembler-x86
>
> Apparently this problem only shows up for x86 when using Sun tools, but
> when using GNU tools, it also shows up for sparc.

Do you have a testcase?  AFAIK the problem only shows up with the Sun tools.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

>> As far as I can understand, it's not possible to build gcc 4.0.0 and 
>> gcc 3.4.* using GNU binutils with current release 2.15 of GNU 
>> binutils. One has to use the CVS sources or at least one file.
> 
> 
> FYI binutils-2.16 has just been released.  You might want to try that.

I have installed binutils-2.16.

Things work better in the sense that I get much farther into building 
the Java libraries. I still hit a problem:

[...]
ar rc .libs/libgcj0_convenience.a [... around 100.000 characters ...]
internal error: error_message(58)
[...]

Is this a known issue?


I guess I should be using GNU's ar instead of Sun's /usr/ccs/bin/ar 
which is probably as much an antique as my version as/ld. It's not the 
first time I see Sun tools choke on very long command lines, so that may 
be the problem here, that or running out of memory:

$ ar -V
ar: Software Generation Utilities (SGU) Solaris-ELF (4.0)
[...]
$


Is there any way to tell the build process to use GNU ar instead of 
/usr/ccs/bin/ar? Would having /usr/ccs/bin in the PATH *after* GNU 
binutils actually be enough?

--
Dimitri Papadopoulos

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

> I have installed binutils-2.16.
> 
> Things work better in the sense that I get much farther into building 
> the Java libraries. I still hit a problem:
> 
> [...]
> ar rc .libs/libgcj0_convenience.a [... around 100.000 characters ...]
> internal error: error_message(58)
> [...]
> 
> Is this a known issue?

I've worked around this by changing all occurrences of AR="ar"  in 
sparc-sun-solaris2.8/libjava/libtool to AR="/usr/local/binutils/bin/ar".
Using GNU's ar fixes the problem indeed.

I have another problem later on, again in sparc-sun-solaris2.8/libjava:

/tmp/GCC/gcc/xgcc -shared-libgcc [...] -o .libs/libgcj.so.6.0.0
collect2: ld terminated with signal 11 [Segmentation Fault]

Any clue? Has anyone attempted to use GNU binutils 2.16 to build gcc on 
Solaris?

In any case it looks like gcc cannot be built on Solaris using standard 
GNU binutils releases.

--
Dimitri Papadopoulos

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> I've worked around this by changing all occurrences of AR="ar"  in
> sparc-sun-solaris2.8/libjava/libtool to AR="/usr/local/binutils/bin/ar".
> Using GNU's ar fixes the problem indeed.
>
> I have another problem later on, again in sparc-sun-solaris2.8/libjava:
>
> /tmp/GCC/gcc/xgcc -shared-libgcc [...] -o .libs/libgcj.so.6.0.0
> collect2: ld terminated with signal 11 [Segmentation Fault]
>
> Any clue?

How did you configure?  The mix of GNU tools and Sun tools looks suspicious.
libgcj.so.6.0.0 is a monster so that could be a memory problem too.  If you're 
not interested in Java, I'd suggest to configure with --disable-libgcj.

> Has anyone attempted to use GNU binutils 2.16 to build gcc on 
> Solaris?

I have (with a 2.16 prerelease) on Solaris 2.5.1, 2.6, 7, 8 and 9.  I'll try 
with the stock release.

> In any case it looks like gcc cannot be built on Solaris using standard
> GNU binutils releases.

2.15 is the only one problematic, unless proven otherwise.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

> How did you configure?  The mix of GNU tools and Sun tools looks suspicious.

I think there's no mix involved.

I have configured with:
	./configure \
		--with-as=/usr/local/binutils/bin/as \
		--with-ld=/usr/local/binutils/bin/ld \
		...
so I should be using GNU's as and ld.

> libgcj.so.6.0.0 is a monster so that could be a memory problem too.  If you're 
> not interested in Java, I'd suggest to configure with --disable-libgcj.

Yes, I do have a first version built with --enable-languages=c,c++ only, 
but I'd like to have a complete version.

Otherwise it's not a memory problem, I have enough memory:
	$ top
	...
	Memory: 1024M real, 243M free, 2457M swap in use, 225M swap free
	...

>>Has anyone attempted to use GNU binutils 2.16 to build gcc on 
>>Solaris?
> 
> 
> I have (with a 2.16 prerelease) on Solaris 2.5.1, 2.6, 7, 8 and 9.  I'll try 
> with the stock release.
> 
> 
>>In any case it looks like gcc cannot be built on Solaris using standard
>>GNU binutils releases.
> 
> 
> 2.15 is the only one problematic, unless proven otherwise.

No, I've had problems with almsot all other previous GNU binutils 
releases, see my previous posts on this list. Maybe GNU binutils 2.13 or 
2.14 did work at some point.

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> > How did you configure?  The mix of GNU tools and Sun tools looks
> > suspicious.
>
> I think there's no mix involved.
>
> I have configured with:
> 	./configure \
> 		--with-as=/usr/local/binutils/bin/as \
> 		--with-ld=/usr/local/binutils/bin/ld \
> 		...
> so I should be using GNU's as and ld.

--with-gnu-as and --with-gnu-ld I presume?

Hacking libtool is not supported anyway. ;-)  I think you should use only GNU 
tools by tweaking your PATH.

> > 2.15 is the only one problematic, unless proven otherwise.
>
> No, I've had problems with almsot all other previous GNU binutils
> releases, see my previous posts on this list.

Including 2.13.x and 2.14?

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

>>I have configured with:
>>	./configure \
>>		--with-as=/usr/local/binutils/bin/as \
>>		--with-ld=/usr/local/binutils/bin/ld \
>>		...
>>so I should be using GNU's as and ld.
> 
> 
> --with-gnu-as and --with-gnu-ld I presume?

No, but configure does detect that, doesn't it? I've never used these
option flags before, I thought they were for HP-UX only. Mmh... I'll
doublecheck.

> Hacking libtool is not supported anyway. ;-)  I think you should use only GNU 
> tools by tweaking your PATH.

Ah, but I'm not hacking anything.

Only in the specific case of sparc-sun-solaris2.8/libjava I had to
switch from Sun's ar to GNU's ar. After building the library that
wouldn't build, I reverted the change to libtool.

This is a new issue and the previous "hack" is totally irrelevant.

>>No, I've had problems with almsot all other previous GNU binutils
>>releases, see my previous posts on this list.
> 
> 
> Including 2.13.x and 2.14?

At least one of them. I'll have to check that, I can't recall which
versions had problems. As far as I can remember I had always upgraded
GNU binutils for specific reasons (the gcc build would fail, the build
of our programs would fail, or our programs would fail).

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

>> libgcj.so.6.0.0 is a monster so that could be a memory problem too.  
>> If you're not interested in Java, I'd suggest to configure with 
>> --disable-libgcj.

Actually I'd like to help fix bugs in the Solaris toolchain, apart from 
compiling my C++ programs.

Using "xgcc -v" instead of plain "xgcc" I've found that the problem 
happens here:
/tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6
collect2: ld returned 1 exit status

Is there a way I can find the exact "ld" command line, in order to 
provide a small testcase for the GNU binutils bugzilla?

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> Actually I'd like to help fix bugs in the Solaris toolchain, apart from
> compiling my C++ programs.
>
> Using "xgcc -v" instead of plain "xgcc" I've found that the problem
> happens here:
> /tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?

Pass -debug to collect2.  I'm not sure this will give you a *small* testcase 
though.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> Actually I'd like to help fix bugs in the Solaris toolchain, apart from
> compiling my C++ programs.
>
> Using "xgcc -v" instead of plain "xgcc" I've found that the problem
> happens here:
> /tmp/GCC/gcc/collect2 [...] /tmp/GCC/gcc/crtn.o -soname libgcj.so.6
> collect2: ld returned 1 exit status
>
> Is there a way I can find the exact "ld" command line, in order to
> provide a small testcase for the GNU binutils bugzilla?

Pass -debug to collect2.  I'm not sure this will give you a *small* testcase 
though.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

> Pass -debug to collect2.  I'm not sure this will give you a *small* testcase 
> though.

/usr/local/binutils/bin/ld [...] -soname libgcj.so.6
[...]
GNU ld version 2.16
   Supported emulations:
    elf32_sparc
    elf64_sparc
/usr/local/binutils/bin/ld: failed to set dynamic section sizes: Memory 
exhausted

Ouch! 1 Mb RAM + 2Mb swap ought to be enough.

I'm wondering what could be eating up memory when the workstation is 
idle, "ps" or "top" don't show any process eating up lots of memory and 
ipcs doesn't show shared memory in use:

$ top
[...]
Memory: 1024M real, 235M free, 2450M swap in use, 231M swap free
[...]
  26336 root       1  59    0  122M 6968K sleep    0:06  0.00% Xsun
    185 root      14  58    0   13M 1984K sleep    0:39  0.00% syslogd
  26354 root       4  59    0 7448K 1808K sleep    0:08  0.00% dtgreet
  26340 root       4  10    0 5416K 1432K sleep    0:00  0.00% dtlogin
    323 root       4  38    0 5200K 1296K sleep    0:01  0.00% dtlogin
    173 root       5  38    0 4968K 2848K sleep  194:15  0.00% automountd
[...]
$

I think I'm going to reboot this workstation and restart...

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> /usr/local/binutils/bin/ld [...] -soname libgcj.so.6
> [...]
> GNU ld version 2.16
>    Supported emulations:
>     elf32_sparc
>     elf64_sparc
> /usr/local/binutils/bin/ld: failed to set dynamic section sizes: Memory
> exhausted
>
> Ouch! 1 Mb RAM + 2Mb swap ought to be enough.

Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not 
be used to build libgcj nowadays. ;-)

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

> Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not 
> be used to build libgcj nowadays. ;-)

Ooops :-)

These were indeed Gb instead of Mb for those wondering...

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Karel Gardas]

On Tue, 10 May 2005, Dimitri Papadopoulos-Orfanos wrote:

> > Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could not
> > be used to build libgcj nowadays. ;-)
>
> Ooops :-)
>
> These were indeed Gb instead of Mb for those wondering...

[have not followed this thread, so sorry if it was already suggested]

BTW: Have you tried to also look at what ulimits are set on your system?

Cheers,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

> BTW: Have you tried to also look at what ulimits are set on your system?

I've rebooted the system and things are really getting better (even 
Sun's "ar" seems to be working now).

This was a kernel problem, the kernel is not up-to-date with patches and 
the workstation hadn't been rebooted for months. There were only 30-40 
processes running, eating less than 300 Mb, but the system was 
nevertheless reporting only a few Mb RAM+swap left.

I'm also using --with-gnu-as and --with-gnu-ld now. At some point these 
were required or made a difference on HP-UX only as far as I can recall; 
I hadn't noticed they were now required or making a difference on 
Solaris too.

--
Dimitri

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> I'm also using --with-gnu-as and --with-gnu-ld now. At some point these
> were required or made a difference on HP-UX only as far as I can recall;
> I hadn't noticed they were now required or making a difference on
> Solaris too.

They should not be required if --with-as and --with-ld are respectively 
specified because the configure machinery will probe in that case.
They are required otherwise because the Sun tools are the default.

-- 
Eric Botcazou

Re: building gcc 4.0.0 on Solaris

[Dimitri Papadopoulos-Orfanos]

Hi,

>>OK, I guess the latest compilers from Sun ship with a better "as".
>>Unfortunately I'm stuck with Sun Studio One 7 for now. Maybe it should
>>be documented that a recent version of "as" is needed by gcc.
> 
> 
> A version not affected by the bug.  4.0.0 bootstraps on Solaris 2.5.1 with
> as: WorkShop Compilers 4.2 dev 13 May 1996
> 
> It looks like we need to document that as: Sun WorkShop 6 99/08/18 is 
> problematic.

FYI our assembler was unpatched. It appears there is a patch 114802 at 
least for Solaris 8 / SPARC:
http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-114802-02-1

This patch fixes the following issues:
4945786 fbe generates incorrect address for modulus operation
1209320 fbe needs a way to declare symbols local by default
4296366 /usr/ccs/bin/as overwrites files instead of replacing them
4351979 108908-01 causes the error of /usr/ccs/bin/as. (value does not 
fit in 32 bits)

I don't understand whether any of these issue descriptions apply to the 
error I was seeing.

Anyway, I've applied the patch:
$ as -V
as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch 114802-02
but didn't have time to try and build gcc with it yet.

--
Dimitri Papadopoulos

Re: building gcc 4.0.0 on Solaris

[James E Wilson]

On Sat, 2005-05-07 at 10:22, Eric Botcazou wrote:
> > Apparently this problem only shows up for x86 when using Sun tools, but
> > when using GNU tools, it also shows up for sparc.
> Do you have a testcase?  AFAIK the problem only shows up with the Sun tools.

I meant when using GCC with the Sun assembler/linker, it shows up on
sparc.  But it doesn't show up on sparc when using Sun cc with Sun
assembler/linker, and thus Sun doesn't document it as a sparc problem.

No, I don't have a testcase.  I was just trying to help answer the
question.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: building gcc 4.0.0 on Solaris

[Eric Botcazou]

> I meant when using GCC with the Sun assembler/linker, it shows up on
> sparc.  But it doesn't show up on sparc when using Sun cc with Sun
> assembler/linker, and thus Sun doesn't document it as a sparc problem.

OK, I misinterpreted "tools", thanks for the clarification.  Yes, that is a 
very plausible explanation.  The problem occurs on SPARC with GCC 32-bit 
because of the switch to DWARF-2 as the default debugging format, while the 
Sun compiler still uses STABS.  Does anyone know what is that of the Sun 
compiler on x86?

I'll try to get my hands on the patched assembler.  If we are lucky, the 
problem was generic and has been fixed on SPARC too.

-- 
Eric Botcazou