I have been given access to a mchine with this architecture and have not, after several evenings at it, been able to complete a single build of gfortran.  I notice some instructions on the gcc web page about some recommended linker to use.

I suspect there are some configuration issues going on here that we need to nail down.  Do we have a "solaris" gcc maintainer around?

(In reply to comment #1)
> I have been given access to a mchine with this architecture and have not, after
> several evenings at it, been able to complete a single build of gfortran.  I
> notice some instructions on the gcc web page about some recommended linker to
> use.
> 
> I suspect there are some configuration issues going on here that we need to
> nail down.  Do we have a "solaris" gcc maintainer around?
> 

I have built GNU binutils on Solaris. If I use GNU-ld, gcc runs fine in 32 bits mode, but is unable to link any 64 bits applications (GNU ld takes 64 bits gcc libraries but tries to link a 32 bits program !). Thus it is not possible to build a 64 bits gcc on solaris with GNU-ld and I have built my gcc with Solaris ld.

If i use only gfortran to compile (gfortran -c) a test program, I haven't find any option to link and run this object.

I suspect a path mistake when gfortran calls ld wrapper.

Regards,

JKB

> I have been given access to a mchine with this architecture and have not,
> after several evenings at it, been able to complete a single build of
> gfortran.

Weird, folks generally can build it flawlessly, see the various build pages:
  http://gcc.gnu.org/gcc-4.1/buildstat.html
  http://gcc.gnu.org/gcc-4.2/buildstat.html
  http://gcc.gnu.org/gcc-4.3/buildstat.html
You indeed need to follow the build instructions.  What happens exactly?

> I suspect there are some configuration issues going on here that we need to
> nail down.  Do we have a "solaris" gcc maintainer around?

I'm the SPARC/Solaris maintainer.  The Fortran compiler has been working fine
on this platform since 4.0.0, like on every other primary platforms.

> There is no error on link stage, but gfortran tries to link program with 32
> bits libraries, not with 64 bits one even I force -m64.

Not quite.  The binary is correctly linked against 64-bit libraries, but the
-R path is not set by default.  You need to set it or set LD_LIBRARY_PATH:

(botcazou@ob) ~ $ gfortran -m64 test.f90
(botcazou@ob) ~ $ ./a.out
ld.so.1: ./a.out: fatal: /nile.build/botcazou/gcc-head/install_sparc/lib/libgfortran.so.3: wrong ELF class: ELFCLASS32
Killed
(botcazou@ob) ~ $ gfortran -m64 test.f90 -Wl,-R,/nile.build/botcazou/gcc-head/install_sparc/lib/sparcv9
(botcazou@ob) ~ $ ./a.out
 Hello, world

(botcazou@ob) ~ $ gfortran -m64 test.f90
(botcazou@ob) ~ $ ./a.out
ld.so.1: ./a.out: fatal: /nile.build/botcazou/gcc-head/install_sparc/lib/libgfortran.so.3: wrong ELF class: ELFCLASS32
Killed
(botcazou@ob) ~ $ export LD_LIBRARY_PATH=/nile.build/botcazou/gcc-head/install_sparc/lib/sparcv9
(botcazou@ob) ~ $ ./a.out
 Hello, world

(In reply to comment #4)
> > There is no error on link stage, but gfortran tries to link program with 32
> > bits libraries, not with 64 bits one even I force -m64.
> 
> Not quite.  The binary is correctly linked against 64-bit libraries, but the
> -R path is not set by default.  You need to set it or set LD_LIBRARY_PATH:
> 
> (botcazou@ob) ~ $ gfortran -m64 test.f90
> (botcazou@ob) ~ $ ./a.out
> ld.so.1: ./a.out: fatal:
> /nile.build/botcazou/gcc-head/install_sparc/lib/libgfortran.so.3: wrong ELF
> class: ELFCLASS32
> Killed
> (botcazou@ob) ~ $ gfortran -m64 test.f90
> -Wl,-R,/nile.build/botcazou/gcc-head/install_sparc/lib/sparcv9
> (botcazou@ob) ~ $ ./a.out
>  Hello, world
> 
> (botcazou@ob) ~ $ gfortran -m64 test.f90
> (botcazou@ob) ~ $ ./a.out
> ld.so.1: ./a.out: fatal:
> /nile.build/botcazou/gcc-head/install_sparc/lib/libgfortran.so.3: wrong ELF
> class: ELFCLASS32
> Killed
> (botcazou@ob) ~ $ export
> LD_LIBRARY_PATH=/nile.build/botcazou/gcc-head/install_sparc/lib/sparcv9
> (botcazou@ob) ~ $ ./a.out
>  Hello, world

Thanks a lot. I'm trying to build my project with LDFLAGS=-Wl,-R,/usr/shared-apps/lib/sparcv9

Is there any issue to direclty fix this mistake in gfortran sources ?

Regards,

JKB

> Is there any issue to direclty fix this mistake in gfortran sources ?

This is not a mistake and this is not specific to fortran:

(botcazou@ob) ~ $ gcc -o t t.c -m64 -shared-libgcc
(botcazou@ob) ~ $ ./t
ld.so.1: ./t: fatal: /nile.build/botcazou/gcc-head/install_sparc/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32

It's just Solaris.

Eric,

Here is the problem I am seeing:

gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \
          main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib -lmpfr -lgmp   -L/usr/lib -L/usr/lib -lmpfr -lgmp
Undefined                       first referenced
 symbol                             in file
libintl_gettext                     c-decl.o
libintl_textdomain                  libbackend.a(intl.o)
libintl_bindtextdomain              libbackend.a(intl.o)
libintl_dgettext                    ../libcpp/libcpp.a(errors.o)
ld: fatal: Symbol referencing errors. No output written to cc1-dummy
collect2: ld returned 1 exit status
gnu-make[3]: *** [cc1-dummy] Error 1
gnu-make[3]: Leaving directory `/home/delisle/gcc/obj44/gcc'
gnu-make[2]: *** [all-stage1-gcc] Error 2
gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44'
gnu-make[1]: *** [stage1-bubble] Error 2
gnu-make[1]: Leaving directory `/home/delisle/gcc/obj44'
gnu-make: *** [all] Error 2

Every time I make an adjustment to configure, I get some other error.  I think maybe the tool chain is broken on this particular machine.

I used this in an empty build directory:

../gcc44/configure --prefix=/home/delisle/gcc/usr --enable-languages=c,fortran --enable-64bit --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-mpfr=/usr --with-gmp=/usr

> gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
> -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
> cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
> c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
> c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
> c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o
> c-omp.o dummy-checksum.o \
>           main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
> ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv
> ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib
> -lmpfr -lgmp   -L/usr/lib -L/usr/lib -lmpfr -lgmp
> Undefined                       first referenced
>  symbol                             in file
> libintl_gettext                     c-decl.o
> libintl_textdomain                  libbackend.a(intl.o)
> libintl_bindtextdomain              libbackend.a(intl.o)
> libintl_dgettext                    ../libcpp/libcpp.a(errors.o)
> ld: fatal: Symbol referencing errors. No output written to cc1-dummy
> collect2: ld returned 1 exit status
> gnu-make[3]: *** [cc1-dummy] Error 1
> gnu-make[3]: Leaving directory `/home/delisle/gcc/obj44/gcc'
> gnu-make[2]: *** [all-stage1-gcc] Error 2
> gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44'
> gnu-make[1]: *** [stage1-bubble] Error 2
> gnu-make[1]: Leaving directory `/home/delisle/gcc/obj44'
> gnu-make: *** [all] Error 2

Ah, yes, this is a classical one, see PR bootstrap/12482.  You can work around
it by passing --disable-nls to the configure script.

That got me farther.  Now this:

gnu-make[3]: Entering directory `/home/delisle/gcc/obj44/gcc'
/home/delisle/gcc/obj44/./prev-gcc/xgcc -B/home/delisle/gcc/obj44/./prev-gcc/ -B/home/delisle/gcc/usr/i386-pc-solaris2.11/bin/  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o sol2-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \
          main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a  -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/delisle/gcc/usr/lib -L/home/delisle/gcc/usr/lib -lmpfr -lgmp   -L/home/delisle/gcc/usr/lib -L/home/delisle/gcc/usr/lib -lmpfr -lgmp
ld: fatal: file /home/delisle/gcc/usr/lib/libgmp.so: wrong ELF class: ELFCLASS64
ld: fatal: file /home/delisle/gcc/usr/lib/libgmp.so: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to cc1-dummy
collect2: ld returned 1 exit status
gnu-make[3]: *** [cc1-dummy] Error 1
gnu-make[3]: Leaving directory `/home/delisle/gcc/obj44/gcc'
gnu-make[2]: *** [all-stage2-gcc] Error 2
gnu-make[2]: Leaving directory `/home/delisle/gcc/obj44'
gnu-make[1]: *** [stage2-bubble] Error 2
gnu-make[1]: Leaving directory `/home/delisle/gcc/obj44'
gnu-make: *** [all] Error 2
$ 

I built gmp and mpfr with defaults.

> I built gmp and mpfr with defaults.

http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2