* building gcc 4.0.0 on Solaris
@ 2005-04-27 15:27 Dimitri Papadopoulos-Orfanos
2005-04-30 19:18 ` Eric Botcazou
2005-05-03 18:54 ` James E Wilson
0 siblings, 2 replies; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-04-27 15:27 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-04-27 15:27 building gcc 4.0.0 on Solaris Dimitri Papadopoulos-Orfanos
@ 2005-04-30 19:18 ` Eric Botcazou
2005-05-02 12:18 ` Dimitri Papadopoulos-Orfanos
2005-05-03 18:54 ` James E Wilson
1 sibling, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-04-30 19:18 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-04-30 19:18 ` Eric Botcazou
@ 2005-05-02 12:18 ` Dimitri Papadopoulos-Orfanos
2005-05-02 13:14 ` Eric Botcazou
0 siblings, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-02 12:18 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-02 12:18 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-02 13:14 ` Eric Botcazou
2005-05-11 12:03 ` Dimitri Papadopoulos-Orfanos
0 siblings, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-02 13:14 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-02 13:14 ` Eric Botcazou
@ 2005-05-11 12:03 ` Dimitri Papadopoulos-Orfanos
0 siblings, 0 replies; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-11 12:03 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-04-27 15:27 building gcc 4.0.0 on Solaris Dimitri Papadopoulos-Orfanos
2005-04-30 19:18 ` Eric Botcazou
@ 2005-05-03 18:54 ` James E Wilson
2005-05-08 8:46 ` Eric Botcazou
2005-05-09 16:35 ` Dimitri Papadopoulos-Orfanos
1 sibling, 2 replies; 24+ messages in thread
From: James E Wilson @ 2005-05-03 18:54 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-03 18:54 ` James E Wilson
@ 2005-05-08 8:46 ` Eric Botcazou
2005-05-12 6:13 ` James E Wilson
2005-05-09 16:35 ` Dimitri Papadopoulos-Orfanos
1 sibling, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-08 8:46 UTC (permalink / raw)
To: James E Wilson; +Cc: gcc, Dimitri Papadopoulos-Orfanos
> > 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-08 8:46 ` Eric Botcazou
@ 2005-05-12 6:13 ` James E Wilson
2005-05-12 10:51 ` Eric Botcazou
0 siblings, 1 reply; 24+ messages in thread
From: James E Wilson @ 2005-05-12 6:13 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc, Dimitri Papadopoulos-Orfanos
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-12 6:13 ` James E Wilson
@ 2005-05-12 10:51 ` Eric Botcazou
0 siblings, 0 replies; 24+ messages in thread
From: Eric Botcazou @ 2005-05-12 10:51 UTC (permalink / raw)
To: James E Wilson; +Cc: gcc, Dimitri Papadopoulos-Orfanos
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-03 18:54 ` James E Wilson
2005-05-08 8:46 ` Eric Botcazou
@ 2005-05-09 16:35 ` Dimitri Papadopoulos-Orfanos
2005-05-10 9:43 ` Dimitri Papadopoulos-Orfanos
1 sibling, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-09 16:35 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-09 16:35 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 9:43 ` Dimitri Papadopoulos-Orfanos
2005-05-10 10:41 ` Eric Botcazou
0 siblings, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 9:43 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 9:43 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 10:41 ` Eric Botcazou
2005-05-10 11:57 ` Dimitri Papadopoulos-Orfanos
0 siblings, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 10:41 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 10:41 ` Eric Botcazou
@ 2005-05-10 11:57 ` Dimitri Papadopoulos-Orfanos
2005-05-10 12:04 ` Eric Botcazou
2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
0 siblings, 2 replies; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 11:57 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 11:57 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 12:04 ` Eric Botcazou
2005-05-10 12:22 ` Dimitri Papadopoulos-Orfanos
2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
1 sibling, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 12:04 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> > 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 12:04 ` Eric Botcazou
@ 2005-05-10 12:22 ` Dimitri Papadopoulos-Orfanos
0 siblings, 0 replies; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 12:22 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 11:57 ` Dimitri Papadopoulos-Orfanos
2005-05-10 12:04 ` Eric Botcazou
@ 2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
2005-05-10 13:06 ` Eric Botcazou
2005-05-10 13:06 ` Eric Botcazou
1 sibling, 2 replies; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 12:56 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 13:06 ` Eric Botcazou
2005-05-10 13:06 ` Eric Botcazou
1 sibling, 0 replies; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 13:06 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
2005-05-10 13:06 ` Eric Botcazou
@ 2005-05-10 13:06 ` Eric Botcazou
2005-05-10 13:36 ` Dimitri Papadopoulos-Orfanos
1 sibling, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 13:06 UTC (permalink / raw)
To: Dimitri; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 13:06 ` Eric Botcazou
@ 2005-05-10 13:36 ` Dimitri Papadopoulos-Orfanos
2005-05-10 18:00 ` Eric Botcazou
0 siblings, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 13:36 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 13:36 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 18:00 ` Eric Botcazou
2005-05-10 18:02 ` Dimitri Papadopoulos-Orfanos
0 siblings, 1 reply; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 18:00 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> /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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 18:00 ` Eric Botcazou
@ 2005-05-10 18:02 ` Dimitri Papadopoulos-Orfanos
2005-05-10 18:05 ` Karel Gardas
0 siblings, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 18:02 UTC (permalink / raw)
To: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 18:02 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 18:05 ` Karel Gardas
2005-05-10 18:55 ` Dimitri Papadopoulos-Orfanos
0 siblings, 1 reply; 24+ messages in thread
From: Karel Gardas @ 2005-05-10 18:05 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 18:05 ` Karel Gardas
@ 2005-05-10 18:55 ` Dimitri Papadopoulos-Orfanos
2005-05-10 19:19 ` Eric Botcazou
0 siblings, 1 reply; 24+ messages in thread
From: Dimitri Papadopoulos-Orfanos @ 2005-05-10 18:55 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: building gcc 4.0.0 on Solaris
2005-05-10 18:55 ` Dimitri Papadopoulos-Orfanos
@ 2005-05-10 19:19 ` Eric Botcazou
0 siblings, 0 replies; 24+ messages in thread
From: Eric Botcazou @ 2005-05-10 19:19 UTC (permalink / raw)
To: Dimitri Papadopoulos-Orfanos; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2005-05-12 6:36 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-27 15:27 building gcc 4.0.0 on Solaris Dimitri Papadopoulos-Orfanos
2005-04-30 19:18 ` Eric Botcazou
2005-05-02 12:18 ` Dimitri Papadopoulos-Orfanos
2005-05-02 13:14 ` Eric Botcazou
2005-05-11 12:03 ` Dimitri Papadopoulos-Orfanos
2005-05-03 18:54 ` James E Wilson
2005-05-08 8:46 ` Eric Botcazou
2005-05-12 6:13 ` James E Wilson
2005-05-12 10:51 ` Eric Botcazou
2005-05-09 16:35 ` Dimitri Papadopoulos-Orfanos
2005-05-10 9:43 ` Dimitri Papadopoulos-Orfanos
2005-05-10 10:41 ` Eric Botcazou
2005-05-10 11:57 ` Dimitri Papadopoulos-Orfanos
2005-05-10 12:04 ` Eric Botcazou
2005-05-10 12:22 ` Dimitri Papadopoulos-Orfanos
2005-05-10 12:56 ` Dimitri Papadopoulos-Orfanos
2005-05-10 13:06 ` Eric Botcazou
2005-05-10 13:06 ` Eric Botcazou
2005-05-10 13:36 ` Dimitri Papadopoulos-Orfanos
2005-05-10 18:00 ` Eric Botcazou
2005-05-10 18:02 ` Dimitri Papadopoulos-Orfanos
2005-05-10 18:05 ` Karel Gardas
2005-05-10 18:55 ` Dimitri Papadopoulos-Orfanos
2005-05-10 19:19 ` Eric Botcazou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).