Building gcc-4.2.4 on Solaris 9

Building gcc-4.2.4 on Solaris 9

[David Eisner]

I'm trying to build gcc-4.2.4 on a 64-bit Solaris 9 SPARC system,
using the Sun Studio compiler (Sun C 5.8).

I'm attempting to build 64-bit binaries (bad idea?).  I've built
64-bit versions of libmpfr and libgmp, and I have CC="cc
-xarch=generic64".  I'm running into a problem when building the stage
2 or stage 3 compiler:

/export/data/software/cradle/build/gcc/objdir/./prev-gcc/xgcc
-B/export/data/software/cradle/build/gcc/objdir/./prev-gcc/
-B/data/software/devtools/gcc-4.2.4-sparc-sun-solaris2.9/sparc-sun-solaris2.9/bin/
  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute    -DHAVE_CONFIG_H  -o f951 \
        fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o
fortran/data.o fortran/decl.o fortran/dump-parse-tree.o
fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o
fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o
fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o
fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o
fortran/simplify.o fortran/st.o fortran/symbol.o fortran/convert.o
fortran/dependency.o fortran/f95-lang.o fortran/trans.o
fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o
fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o
fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o
fortran/trans-types.o main.o  libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a
-L/data/software/devtools/gmp-4.2.1-sparc-sun-solaris2.9/lib
-L/data/software/devtools/mpfr-2.3.0-sparc-sun-solaris2.9/lib -lmpfr
-lgmp ../libcpp/libcpp.a ./../intl/libintl.a  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
ld: fatal: file
/data/software/devtools/mpfr-2.3.0-sparc-sun-solaris2.9/lib/libmpfr.so:
wrong ELF class: ELFCLASS64
ld: fatal: file
/data/software/devtools/gmp-4.2.1-sparc-sun-solaris2.9/lib/libgmp.so:
wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to f951
collect2: ld returned 1 exit status
make[3]: *** [f951] Error 1


The problem is that fortran .o files are 32-bit, not 64-bit:

cannes [objdir]$ file gcc/fortran/arith.o
gcc/fortran/arith.o:    ELF 32-bit MSB relocatable SPARC32PLUS Version
1, V8+ Required

What's the proper way to tell the later stage compilers to produce
64-bit binaries?

Thanks.

-David

-- 
David Eisner http://cradle.brokenglass.com

RE: Building gcc-4.2.4 on Solaris 9

[Jay]

> -Forwarded Message Attachment-- 
> Date: Tue, 29 Jul 2008 
> [D] From: David 
>  To: gcc-help@gcc.gnu.org 
> Subject: Building gcc-4.2.4 on Solaris 9 

> [D] I'm trying to build gcc-4.2.4 on a 64-bit Solaris 9 SPARC system, 
> [D] using the Sun Studio compiler (Sun C 5.8). 

> [D] I'm attempting to build 64-bit binaries (bad idea?).  I've built  
> [D] 64-bit versions of libmpfr and libgmp, and I have CC="cc  
> [D] -xarch=generic64".  I'm running into a problem when building the stage  
 
> [D] ld: fatal: file  
> [D] /data/software/devtools/mpfr-2.3.0-sparc-sun-solaris2.9/lib/libmpfr.so:  
> [D] wrong ELF class: ELFCLASS64  
> [D] ld: fatal: file  

> [D] The problem is that fortran .o files are 32-bit, not 64-bit: 

 Personally, I would just avoid the "biarch"-ness (don't set
 CC and/or CFLAGS) and *some* of the automatic
 guessing of host/build/target and do this:

run config.guess
probably it will say sparc-sun-solaris2.9.

Then do this:

  mkdir /obj  
  cd /obj  
  /src/configure \
   -disable-nls \
   -build sparc-sun-solaris2.9 \  (ok, you can omit this line, -build is always correctly guessed in my brief experience) 
   -host sparc64-sun-solaris2.9 \
   -target sparc64-sun-solaris2.9 

 (Single dash options are clearly supported by configure.) 

Also, it is a bit of a time sink, but you can stick the gmp and mpfr source right into the gcc source tree and it'll build "all at once". (renaming mpfr-2.3.0 to mpfr, etc.) 
In fact, that might help you, since it'll net you sparc32 and sparc64 if needed.

This definitely won't be the quickest way.
Quicker would be to set CC/CFLAGS and use -disable-bootstrap.


 - Jay

Re: Building gcc-4.2.4 on Solaris 9

[David Eisner]

On Wed, Jul 30, 2008 at 7:56 AM, Jay <jayk123@hotmail.com> wrote:
> This definitely won't be the quickest way.
> Quicker would be to set CC/CFLAGS and use -disable-bootstrap.

Before I try your suggestions, another question:  It seems like
setting BOOT_CFLAGS to include "-m64" should do what I want.  The
Makefile says:

  # BOOT_CFLAGS is the value of CFLAGS to pass to the stage2, stage3 and stage4
  # bootstrap compilations.

If I understand this correctly, this would cause gcc from the later
stages to be called with -m64, so that they would, when building the
compiler, produce 64-bit objects and be able to link against my 64-bit
libgmp and libmpfr.  Is this right?

Thanks.

-David


-- 
David Eisner http://cradle.brokenglass.com

RE: Building gcc-4.2.4 on Solaris 9

[Jay]

 On Wed, Jul 30, 2008 at 7:56 AM, Jay  wrote:
  [Jay] This definitely won't be the quickest way.
  [J] Quicker would be to set CC/CFLAGS and use -disable-bootstrap.

 [David] Before I try your suggestions, another question: It seems like
 [D] setting BOOT_CFLAGS to include "-m64" should do what I want. The
 [D] Makefile says:

 [D] # BOOT_CFLAGS is the value of CFLAGS to pass to the stage2, stage3 and stage4
 [D] # bootstrap compilations.

 [D] If I understand this correctly, this would cause gcc from the later
 [D] stages to be called with -m64, so that they would, when building the
 [D] compiler, produce 64-bit objects and be able to link against my 64-bit
 [D] libgmp and libmpfr. Is this right?

Maybe. I don't know. There are many options..

 I should clarify/correct, that another thing i would try, which might
 have the advantage of
 - working vs. not-working
 - leaving you with more functionality installed in the end, maybe for the same time cost


is first build a sparc(32) => sparc64 cross compiler
 install it
 and then a native sparc64 => sparc64

  mkdir /obj/1
 cd /obj/1
 /src/configure -host sparc-sun-solaris2.9 -target sparc64-sun-solaris2.9 -disable-bootstrap -disable-nls -disable-multilib -enable-languages=c,c++ -verbose 
 make 
 sudo make install 

In truth, you can stop here. The next part doesn't buy much. (numbers as to the perf of gcc -host sparc vs. -host sparc64? or more generally foo vs. foo64?)  

   mkdir /obj/2 
   cd /obj/2  
  # following line identical to above but for -host sparc vs. -host sparc64  
  /src/configure -host sparc64-sun-solaris2.9 -target sparc64-sun-solaris2.9 -disable-bootstrap -disable-nls -disable-multilib -enable-languages=c,c++ -verbose 
  make
  sudo make install

Personally I am bothered by the fact that this rebuilds a lot of the same code the same way multiple times.
 e.g. libiberty.
 However if you can spare the day of waiting and want it to just work and don't care about making it faster for future runs,
 this direct approach should work.

I am working on a "system" (ie: a little bit of code) that minimize the rebuilds and reconfigurations and non-use of config.cache.
 For example, if I am building multiple toolsets, with "some overlap" -- e.g. same build/host, varying target, I shouldn't have to
 compile libiberty more than once per platform. Likewise for binutils, if I -enable-targets=all (but -enable-targets=all has small problems in bfd/opcodes,
 and doesn't currently work with ld, gas, and certainly gcc).
 I'd really like gcc, ld, as all take a -target command line parameter, and have gcc/cc1/as run in just one process, possibly
 compiling multiple source files (e.g. Visual C++ cl -c 1.c 2.c 3.c vs. gcc -c 1.c 2.c 3.c -- one process vs. seven!)
 But I until I have this working well...

- Jay