RE: Build failure for sparc-sun-solaris2.10

2014-08-01 Thread Arthur Haas 
> Hi Art,

Hi. Thanks for helping me try to fix the build problem I'm seeing.

{ ... snip ... }
> Could be, see above.  Apart from that, I wonder why you insist on using
> GNU ld on Solaris.  install.texi strongly suggests to use the Solaris
> linker instead, and I stand by that advise.

> A couple of comments on those configure options: avoid everything not
> strictly necessary and stay with the defaults.

{ ... snip ... }

I had a small script which runs 'configure' and using GNU as/ld had worked. I've
adjusted the script so that GCC is configured to use Sun /usr/ccs/bin/ld instead
of the GNU ld binary, and I also got rid of '--enable-threads' and the
'--enable-libstdcxx-pch=no' options

With the adjustments to the configuration my build got past the 'libgcc_s.so' 
error
I'd been seeing, and proceeded into the 'stage2' build before it failed:

libtool: link:  /export/home/arth/src/gcc-0801/./prev-gcc/xgcc -B/export/home/ar
th/src/gcc-0801/./prev-gcc/ -B/export/home/arth/local/sparc-sun-solaris2.10/bin/
 -B/export/home/arth/local/sparc-sun-solaris2.10/bin/ -B/export/home/arth/local/
sparc-sun-solaris2.10/lib/ -isystem /export/home/arth/local/sparc-sun-solaris2.1
0/include -isystem /export/home/arth/local/sparc-sun-solaris2.10/sys-include
-shared  .libs/lto-plugin.o-static-libgcc -static-libstdc++ -static-libgcc .
./libiberty/pic/libiberty.a   -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto
_plugin.so.0.0.0
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
ld: fatal: File processing errors. No output written to .libs/liblto_plugin.so.0
.0.0
collect2: error: ld returned 1 exit status
gmake[4]: *** [liblto_plugin.la] Error 1
gmake[4]: Leaving directory `/export/home/arth/src/gcc-0801/lto-plugin'

I copied the failing link into a script, added a '-v' option to see what was 
going
on, and the link command was this:

/export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M 
/export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map -Y P,/lib:/usr/lib 
-Qy -o .libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o /usr/lib/values-Xa.o 
/export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o 
-L/export/home/arth/src/gcc-0801/./prev-gcc 
-L/export/home/arth/local/sparc-sun-solaris2.10/bin 
-L/export/home/arth/local/sparc-sun-solaris2.10/bin 
-L/export/home/arth/local/sparc-sun-solaris2.10/lib .libs/lto-plugin.o 
../libiberty/pic/libiberty.a -soname liblto_plugin.so.0 -lgcc -lgcc_eh -lc 
-lgcc -lgcc_eh -lc /export/home/arth/src/gcc-0801/./prev-gcc/crtend.o 
/usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file liblto_plugin.so.0: open failed: No such file or directory
ld: fatal: File processing errors. No output written to 
.libs/liblto_plugin.so.0.0.0
collect2: error: ld returned 1 exit status

The warning about the '-o' option appearing twice was really strange until I 
found out through some trial and error that the '-soname' option was the cause. 
If I run that command above but use the '-h' option instead the shared object 
links successfully:

$ /export/home/arth/src/gcc-0801/./prev-gcc/collect2 -V -G -dy -z text -M 
/export/home/arth/src/gcc-0801/./prev-gcc/libgcc-unwind.map  -Y P,/lib:/usr/lib 
-Qy -o ./.libs/liblto_plugin.so.0.0.0 /usr/lib/crti.o /usr/lib/values-Xa.o 
/export/home/arth/src/gcc-0801/./prev-gcc/crtbegin.o 
-L/export/home/arth/src/gcc-0801/prev-gcc 
-L/export/home/arth/local/sparc-sun-solaris-2.10/bin 
-L/export/home/arth/local/sparc-sun-solaris-2.10/bin 
-L/export/home/arth/local/sparc-sun-solaris-2.10/lib ./.libs/lto-plugin.o 
../libiberty/pic/libiberty.a -h liblto_plugin.so.0 -lgcc -lgcc_eh -lc -lgcc 
-lgcc_eh -lc /export/home/arth/src/gcc-0801/prev-gcc/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
$

I guess now the trick is figuring out how to have the collect2 program use '-h' 
instead of '-soname' when it invokes the Sun linker. Suggestions?

Thanks in advance.

Art Haas

RE: Build failure for sparc-sun-solaris2.10

2014-08-05 Thread Arthur Haas 
> Hi Art,

Hello.

>> Could be, see above.  Apart from that, I wonder why you insist on using
>> GNU ld on Solaris.  install.texi strongly suggests to use the Solaris
>> linker instead, and I stand by that advise.
>
>> A couple of comments on those configure options: avoid everything not
>> strictly necessary and stay with the defaults.
> { ... snip build error ... }

> it seems something is very wrong here.  The use of -M
> .../libgcc-unwind.map indicates that gcc configure thinks that the
> Solaris ld (/usr/ccs/bin/ld) is in ise, while libtool is invoking the
> linker with -soname, which only happens for GNU ld.

> How exactly did you configure gcc to use the system linker?  If all else
> fails, I suggest to use --without-gnu-ld --with-ld=/usr/ccs/bin/ld to
> make certain the right one is in use.  One possible cause of your
> problems could be if you have GNU ld in your path called ld.  I've never
> done that (I always call it gld-), but the above configure
> options should help if you are unable to get rid of such an ld.

I tried the '--without-gnu-ld --with-ld=/usr/ccs/bin/ld' configure options
and my build failed again as my GNU 'ld' binary was again being found. So
the next step was to rename my installed GNU 'ld' to 'ld-2.24' and adjust
my $PATH so that the directory where it was installed wouldn't be found, and
rebuild. I'm happy to report this build was a success:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.10.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /export/home/arth/src/gcc.git/configure 
--prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls 
--with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local 
--with-mpc=/export/home/arth/local --enable-checking=release 
--with-as=/export/home/arth/local/bin/as --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.10.0 20140804 (experimental) [master revision 
0549e5a:2217af7:347a47cbf5f8ee0bc7e11dc97703b318d3ff259c] (GCC)
$

Thanks for your help in resolving this and maintaining the Solaris port.

Art Haas

RE: Build failure in libgfortran on i386-pc-solaris2.10

2009-08-25 Thread Arthur Haas 
 
>> Art Haas  writes:

>> My bootstrap builds have been failing in the 'libgfortran' portion
>>  of the build since this patch:
>> 
>> 2009-07-27  Tobias Burnus  
>> 
>> PR fortran/40863
>> * c99_functions.c: Define complex I, if not defined.
>> Create prototypes for C99 functions to silence warnings.
>> * gfortran.map: Add missing functions to GFORTRAN_C99_1.0
>> and new GFORTRAN_C99_1.1.
>> 
>> Here's the error message from the build log:
>> 
> [ ... snip error message ... ]
> I've got the same problem on both Solaris 10/x86 and Solaris 11/SPARC
(and
> most likely, IRIX 6.5 will be affected, too).  I've file PR
> libfortran/41169 for the issue, assigned to Tobias.

> It seems that the underlying issue is a problem in GCC's complex
support on
> Solaris 2, though.

I've stopped building the fortran compiler for the moment. I haven't dug
into what preprocessor trickery is needed to get this code to build just
yet. I will keep an eye on the PR and be glad to test any potential
patches offered.

Art Haas

RE: Bootstrap failures on i386-pc-solaris2.10

2010-04-01 Thread Arthur Haas 
I'll update my repo shortly and replace the '--with-arch' and '--with-tune' 
arguments as you suggest. As for the '--disable-libstdcxx-pch'
argument, I had build problems months ago and this argument fixed the problem, 
although now looking at the configure script for libstdc
it looks like the correct argument should be '--enable-libstdcxx-pch=no' if it 
is to be used. The '--enable-threads' argument is another configuration option 
I added long ago as well. The script which configures and starts my GCC builds 
needs some cleanup ...

Thanks.

Art Haas

-Original Message-
From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
Sent: Thursday, April 01, 2010 9:25 AM
To: Arthur Haas
Cc: gcc@gcc.gnu.org
Subject: Re: Bootstrap failures on i386-pc-solaris2.10

Hi Art,

> My builds on my X86 solaris box have failed since yesterday, and
> I've just found bug 43615 in Bugzilla which indicates a different
> but similar issue for an x86-64 build.I'm running Solaris 10 on an
> older Dell box with a Pentium4 chip, and have been building
> gcc with the '--disable-multilib' argument for quite some time.
>
> Here's the config info from the last build which worked:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
> Target: i386-pc-solaris2.10
> Configured with: /home/ahaas/gnu/gcc.git/configure 
> --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran 
> --disable-nls --with-gmp=/export/home/arth/local 
> --with-mpfr=/export/home/arth/local --enable-checking=release 
> --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as 
> --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib 
> --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10 
> --with-arch=pentium4 --with-tune=pentium4
> Thread model: posix
> gcc version 4.5.0 20100330 (experimental) (GCC)
>
> Here's the last bits of today's build log - the '--disable-multilib' configure
> option should have skipped the 'amd64' stuff below ...

The --disable-multilib option has been broken by a recent patch.  This
is a known bug and will hopefully be fixed soon.

Configuring with --with-arch=pentium4 --with-tune=pentium4 is wrong and
doesn't work in the general case, as you've discovered, since it breaks
the 64-bit support.  You just didn't notice the problem before due to
--disable-multilib.  Use --with-arch_32=pentium4 --with-tune_32=pentium4
instead, or simply update to current mainline: my patch to default the
i?86-*-solaris2* configurations to pentium4 just went in.

As for the other configure options: --enable-threads is superfluous,
it's the default.  What are you trying to achieve with
--disable-libstdcxx-pch?

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: Bootstrap failures on i386-pc-solaris2.10

2010-04-01 Thread Arthur Haas 
By updating to the lastest code in the trunk, and removing the '--with-arch' 
and '--with-tune' options from my configuration, I've successfully built the 
latest GCC code. I'll be removing the '--disable-multilib' option from my build 
configuration now also.

Thanks.

Art Haas

-Original Message-
From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
Sent: Thursday, April 01, 2010 9:25 AM
To: Arthur Haas
Cc: gcc@gcc.gnu.org
Subject: Re: Bootstrap failures on i386-pc-solaris2.10

Hi Art,

> My builds on my X86 solaris box have failed since yesterday, and
> I've just found bug 43615 in Bugzilla which indicates a different
> but similar issue for an x86-64 build.I'm running Solaris 10 on an
> older Dell box with a Pentium4 chip, and have been building
> gcc with the '--disable-multilib' argument for quite some time.
>
> Here's the config info from the last build which worked:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
> Target: i386-pc-solaris2.10
> Configured with: /home/ahaas/gnu/gcc.git/configure 
> --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran 
> --disable-nls --with-gmp=/export/home/arth/local 
> --with-mpfr=/export/home/arth/local --enable-checking=release 
> --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as 
> --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib 
> --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10 
> --with-arch=pentium4 --with-tune=pentium4
> Thread model: posix
> gcc version 4.5.0 20100330 (experimental) (GCC)
>
> Here's the last bits of today's build log - the '--disable-multilib' configure
> option should have skipped the 'amd64' stuff below ...

The --disable-multilib option has been broken by a recent patch.  This
is a known bug and will hopefully be fixed soon.

Configuring with --with-arch=pentium4 --with-tune=pentium4 is wrong and
doesn't work in the general case, as you've discovered, since it breaks
the 64-bit support.  You just didn't notice the problem before due to
--disable-multilib.  Use --with-arch_32=pentium4 --with-tune_32=pentium4
instead, or simply update to current mainline: my patch to default the
i?86-*-solaris2* configurations to pentium4 just went in.

As for the other configure options: --enable-threads is superfluous,
it's the default.  What are you trying to achieve with
--disable-libstdcxx-pch?

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: Bootstrap failures on solaris

2009-06-09 Thread Arthur Haas 
>Revital1 Eres  writes:
>> Hello,
>>
>>> i386-pc-solaris:
>>>
>>> cc1: warnings being treated as errors
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In
function
>>> 'loop_prefetch_arrays':
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7:
error:
>>>
>>> format '%ld' expects type 'long int', but argument 5 has type 'long
long
>> int'
>>> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
>>> make[3]: *** Waiting for unfinished jobs
>>
>> I get this error on ppc also.
>
> See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00712.html

Hi.

Now that this patch has been commited, the build on i386-pc-solaris2.10
succeeds when building tree-ssa-loop-prefetch.o file but fails later on:

cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/gcc.c: In function 'compare_files':
/export/home/arth/gnu/gcc.git/gcc/gcc.c:6635:2: error: request for
implicit conversion from 'void *' to 'caddr_t' not permitted in C++
make[3]: *** [gcc.o] Error 1
make[3]: *** Waiting for unfinished jobs

The error is in an munmap() call, and a look at the  header
shows that the funcation arguments can be either 'void *' or 'caddr_t *'
depending on preprocessor values.

Art Haas

RE: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

2010-06-04 Thread Arthur Haas 
Hi.

The patch resolves the build failures.

Thanks.

Art Haas

-Original Message-
From: Nathan Froyd [mailto:froy...@codesourcery.com]
Sent: Friday, June 04, 2010 12:29 PM
To: Ian Lance Taylor
Cc: Arthur Haas; gcc@gcc.gnu.org
Subject: Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd  writes:
> > Looking at things a little more closely, output_address is exported in
> > output.h.  I suppose output_operand should be exported there as well?
>
> Yes, put the declaration there, by output_operand_lossage.

This is what I committed.

-Nathan

* config/i386/i386-protos.h (ix86_print_operand): Declare.
* config/i386/i386.c (ix86_print_operand): Make non-static.
* config/i386/sol2.h (ASM_OUTPUT_CALL): Call ix86_print_operand.
* output.h (output_operand): Declare.
* final.c (output_operand): Make non-static.

Index: final.c
===
--- final.c (revision 160285)
+++ final.c (working copy)
@@ -220,7 +220,6 @@ static void output_asm_name (void);
 static void output_alternate_entry_point (FILE *, rtx);
 static tree get_mem_expr_from_op (rtx, int *);
 static void output_asm_operand_names (rtx *, int *, int);
-static void output_operand (rtx, int);
 #ifdef LEAF_REGISTERS
 static void leaf_renumber_regs (rtx);
 #endif
@@ -3478,7 +3477,7 @@ mark_symbol_refs_as_used (rtx x)
The meanings of the letters are machine-dependent and controlled
by TARGET_PRINT_OPERAND.  */

-static void
+void
 output_operand (rtx x, int code ATTRIBUTE_UNUSED)
 {
   if (x && GET_CODE (x) == SUBREG)
Index: ChangeLog
===
Index: output.h
===
--- output.h(revision 160285)
+++ output.h(working copy)
@@ -77,6 +77,9 @@ extern rtx final_scan_insn (rtx, FILE *,
subreg of.  */
 extern rtx alter_subreg (rtx *);

+/* Print an operand using machine-dependent assembler syntax.  */
+extern void output_operand (rtx, int);
+
 /* Report inconsistency between the assembler template and the operands.
In an `asm', it's the user's fault; otherwise, the compiler's fault.  */
 extern void output_operand_lossage (const char *, ...) ATTRIBUTE_PRINTF_1;
Index: config/i386/sol2.h
===
--- config/i386/sol2.h  (revision 160285)
+++ config/i386/sol2.h  (working copy)
@@ -145,7 +145,7 @@ along with GCC; see the file COPYING3.
   do   \
 {  \
   fprintf (FILE, "\tcall\t");  \
-  print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P');  \
+  ix86_print_operand (FILE, XEXP (DECL_RTL (FN), 0), 'P'); \
   fprintf (FILE, "\n");\
 }  \
   while (0)
Index: config/i386/i386-protos.h
===
--- config/i386/i386-protos.h   (revision 160285)
+++ config/i386/i386-protos.h   (working copy)
@@ -60,6 +60,7 @@ extern bool legitimate_pic_operand_p (rt
 extern int legitimate_pic_address_disp_p (rtx);

 extern void print_reg (rtx, int, FILE*);
+extern void ix86_print_operand (FILE *, rtx, int);
 extern bool output_addr_const_extra (FILE*, rtx);

 extern void split_di (rtx[], int, rtx[], rtx[]);
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 160285)
+++ config/i386/i386.c  (working copy)
@@ -11579,7 +11579,7 @@ get_some_local_dynamic_name (void)
; -- print a semicolon (after prefixes due to bug in older gas).
  */

-static void
+void
 ix86_print_operand (FILE *file, rtx x, int code)
 {
   if (code)

RE: Bootstrap failures on sparc/x86 solaris2.10 machines

2010-10-14 Thread Arthur Haas 
> Hi Art,

>> No luck with this mornings builds on both x86 and sparc.
>>
>> My last successful i386-pc-solaris2.10 build was several weeks ago; all
> the build attempts fail at this assertion in the function/file below:
>> { ... snip ... }

> I'm building mainline on Solaris 8 to 11 with both Sun as and gas all
> the time without problems, though I'm very rarely using GNU ld
> (install.texi warns against doing so for a reason).  What version of gld
> are you using above?  I recently found a couple of bugs with CVS
> binutils and am in the process of fixing them.  In the rare attempts of
> building with gld, I've never seen a problem as you report, so please
> file a bug for this issue.  Also, please try to use Sun ld and see if
> this helps.

A build using Sun 'ld' also failed in a similar manner.

I've added the bug to GCC bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018


>> { ... snip sparc bug error ... }
> Known bug, already fixed:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00942.html

My sparc builds are working fine now. Thanks!

Art Haas

RE: Bootstrap errors on i386-pc-solaris2.10 bisected

2010-10-14 Thread Arthur Haas 

>> On Tue, Oct 12, 2010 at 2:46 PM, Art Haas  wrote:
>> Hi.
>>
>> The bootstrap problems I've been having on the x86 Solaris machine,
>> plus the reply from maintainer Rainer Orth that his builds have
>> been succeeding were the impetus to investigate how 'git bisect'
>> works. After a bit of fumbling around, including a rebuild of
>> an apparently miscompiled 'git' binary, I was able to bisect
>> the build problems to this commit:
>> { ... snip ... }

> It could be:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865

I tried the one-line patch at the end of the bug report and it did not help.

Art Haas

Bootstrap failure in sparc-sun-solaris2.10

2008-09-12 Thread Arthur Haas 
Hi.

Even with the patch listed in the bug report below my bootstrap would
still fail when the compiler tries to build libgcc.

The bug report for the bootstrap failure is here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424

The build failed while building libgcc - the code would trip up on an
assert in haifa-sched.c, similar to the message posted here, though now
the assert is on line 2318:

http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html

Applying the patch Adam created and posted in the message below resolved
the issue and the compiler successfully bootstrapped:

http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html

There was one reply to this message; I don't know if the patch is being
reworked or been formally submitted yet, but it did fix my build.

Art Haas

RE: Bootstrap failed on i386-pc-solaris2.10

2007-08-08 Thread Arthur Haas 

> -Original Message-
> [ ... snip ... ]
> 
> > CRTSTUFF_T_CFLAGS_S = $(CRTSTUFF_T_CFLAGS) -fPIC
> > 
> > How do you use +=?
> 
> Sorry, I was looking at an old checkout.
> 
> Could you simply test patching config/i386/t-crtstuff like this:
> 
> -CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer 
> -fno-asynchronous-unwind-tables
> +CRTSTUFF_T_CFLAGS += -fno-omit-frame-pointer 
> -fno-asynchronous-unwind-tables
> 
> (It would be great if you, H.J., tested on Linux, and Art tested on 
> Solaris 10).
> 
> Thanks,
> 
> Paolo

Hi.

Making the change above results in a successful build. Quite a
difference what a '+' can make.

Art Haas