* RE: Building gcc-4.2.4 on Solaris 9 [not found] <1217413077.17216.ezmlm@gcc.gnu.org> @ 2008-07-30 14:15 ` Jay 2008-07-30 16:45 ` David Eisner 0 siblings, 1 reply; 4+ messages in thread From: Jay @ 2008-07-30 14:15 UTC (permalink / raw) To: deisner, gcc-help > -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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Building gcc-4.2.4 on Solaris 9 2008-07-30 14:15 ` Building gcc-4.2.4 on Solaris 9 Jay @ 2008-07-30 16:45 ` David Eisner 0 siblings, 0 replies; 4+ messages in thread From: David Eisner @ 2008-07-30 16:45 UTC (permalink / raw) To: Jay; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <1217501358.30475.ezmlm@gcc.gnu.org>]
* RE: Building gcc-4.2.4 on Solaris 9 [not found] <1217501358.30475.ezmlm@gcc.gnu.org> @ 2008-07-31 17:03 ` Jay 0 siblings, 0 replies; 4+ messages in thread From: Jay @ 2008-07-31 17:03 UTC (permalink / raw) To: gcc-help, deisner 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Building gcc-4.2.4 on Solaris 9 @ 2008-07-29 15:04 David Eisner 0 siblings, 0 replies; 4+ messages in thread From: David Eisner @ 2008-07-29 15:04 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-07-31 11:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1217413077.17216.ezmlm@gcc.gnu.org> 2008-07-30 14:15 ` Building gcc-4.2.4 on Solaris 9 Jay 2008-07-30 16:45 ` David Eisner [not found] <1217501358.30475.ezmlm@gcc.gnu.org> 2008-07-31 17:03 ` Jay 2008-07-29 15:04 David Eisner
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).