/bin/sh is not supported on SPARC/Solaris.  Please read the instructions at:
  http://gcc.gnu.org/install/specific.html#x-x-solaris2

ah, thanks.  Never hit that issue with any gcc release until now.

Actually, the problem has nothing to do with using /bin/sh, because I get the same failure using /bin/ksh, too:

/bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-srk-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > selected_real_kind.inc || rm selected_real_kind.inc
/bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h
../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh: Unknown type
grep '^#' < kinds.h > kinds.inc
/bin/ksh: kinds.h: cannot open
make[3]: *** [kinds.inc] Error 1
make[3]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/sparc-sun-solaris2.9/libgfortran'
make[2]: *** [all-target-libgfortran] Error 2
make[2]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59'
make: *** [bootstrap] Error 2

> Actually, the problem has nothing to do with using /bin/sh, because I get the
> same failure using /bin/ksh, too:

OK, but given that you're the first who reports that kind of problems, we're pretty much in the dark for the time being so we have to try the strictly adhere to the proven guidelines.

It looks like the Fortran compiler doesn't work at all on your systems.  Are you sure the shared GMP/MFPR libraries are in your LD_LIBRARY_PATH?

Yep.  That's how f951 was getting linked to gmp.  I'm going to make gmp only be static, however, and see if that changes things.

I'm going to have to defer further work on both these bugs until next week.  I had a very narrow window of opportunity for upgrading gcc for the campus (spring break), and now I have to back out all the gcc bits I've done so that I can release other software to the campus that needs updating.  Next week I'll be able to start poking at gcc again.

--Quanah

i hit this same issue and the real error was being masked by the shell script:
if $compile -c tmp$$.f90 > /dev/null 2>&1; then

turns out the compile step was ICEing resulting in $largest_ctype not being reset from "" ... so the only error you see is "Unknown type"

guess give `make check` a run in the mpfr package and see if it's being miscompiled

I will be working on this after the students leave, starting in June.  Please keep this ticket open.

I note that the versions of GMP & MPFR I'm using work *fine* on linux, so I consider them "known good".  They only don't work with Solaris.

(In reply to comment #7)
> I will be working on this after the students leave, starting in June.  Please
> keep this ticket open.

OK.

> I note that the versions of GMP & MPFR I'm using work *fine* on linux, so I
> consider them "known good".  They only don't work with Solaris.

I was talking about the compiled binaries. My definition of a "working" GMP & MPFR is:
  -- it's recent enough (you should try GMP 4.2.1 and MPFR 2.2.0)
  -- it passes all the checks (make check in both packages)

> I note that the versions of GMP & MPFR I'm using work *fine* on linux, so I
> consider them "known good".  They only don't work with Solaris.

I definitely cannot reproduce this problem either.

I have seen the same mistake with gcc 4.1.1 on a dual HyperSPARC running Solaris 9. GMP & MPFR are good (tested with make check). My Solaris has a working /bin/sh.

JKB

> I have seen the same mistake with gcc 4.1.1 on a dual HyperSPARC running
> Solaris 9. GMP & MPFR are good (tested with make check).

This has something to do with GMP & MPFR.  Make sure they are built as 32-bit libraries.  See http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2.

> My Solaris has a working /bin/sh.

Never say that. :-)  /bin/sh is riddled with bugs on Solaris, use /bin/ksh as prescribed in http://gcc.gnu.org/install/specific.html#x-x-solaris2.

Eric,

I have configured gcc with:
lebegue:[~/gcc-4.1.1/build] > ../configure --prefix=/opt --enable-threads=posix --enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld --with-mpfr=/opt --disable-multilib && make -j2 bootstrap

thus I only build gcc for a 32 bits solaris system. I have tried to use ksh, and now, I obtain:

cp ../../../libgfortran/config/fpu-sysv.h fpu-target.h
grep '^#' < kinds.h > kinds.inc
/bin/ksh: kinds.h: cannot open
make[3]: *** [kinds.inc] Error 1
make[3]: Leaving directory `/home/bertrand/gcc-4.1.1/build/sparc-sun-solaris2.9/libgfortran'
make[2]: *** [all-target-libgfortran] Error 2
make[2]: *** Waiting for unfinished jobs....

I need gfortran and I don't understand where is the mistake and why you cannot reproduce this bug.

Regards,

JKB

> I have configured gcc with:
> lebegue:[~/gcc-4.1.1/build] > ../configure --prefix=/opt --enable-threads=posix
> --enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld
> --with-mpfr=/opt --disable-multilib && make -j2 bootstrap
> 
> thus I only build gcc for a 32 bits solaris system.

The problem is GMP & MPFR: on Solaris, they are built as 64-bit libraries by default.  Since you want to build a 32-bit compiler, this cannot work.  So you have to coax them into being 32-bit libraries, with the trick given on the page I mentioned.

> I need gfortran and I don't understand where is the mistake and why you
> cannot reproduce this bug.

Maybe because I don't use the same GMP & MPFR.  Everything works fine with GMP 4.1.3 + bundled MPFR on all versions of SPARC/Solaris from 2.5.1 to 10 so I'm not really thrilled with upgrading, there would probably be little benefit for
the compiler.  I should probably add a blurb about that on the configuration
page.

Now if you posted the *exact* versions and configure lines and make lines for
both the GMP and MPFR you use, I could again give it a whirl.

GMP-4.2
./configure --prefix=/opt --with-gnu-ld --disable-cxx  --disable-nails  --disable-mpfr
MPFR-2.2
./configure --enable-mpfr --with-gmp-=/opt --prefix=/opt --with-gmp-lib=/opt --with-gmp-include=/opt && make -j2

I think that both libraries are 32 bits libraries, not 64.

GCC
../configure --prefix=/opt --enable-threads=posix --enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld --with-mpfr=/opt --disable-multilib && make -j2 bootstrap

(In reply to comment #14)
> GMP-4.2
> ./configure --prefix=/opt --with-gnu-ld --disable-cxx  --disable-nails 
> --disable-mpfr
> MPFR-2.2
> ./configure --enable-mpfr --with-gmp-=/opt --prefix=/opt --with-gmp-lib=/opt
> --with-gmp-include=/opt && make -j2
> 
> I think that both libraries are 32 bits libraries, not 64.
> 
> GCC
> ../configure --prefix=/opt --enable-threads=posix
> --enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld
> --with-mpfr=/opt --disable-multilib && make -j2 bootstrap
> 

Try adding ABI=32 to the GMP options.  I don't have a SPARC box, but on AIX-ppc, this was necessary to force GMP to build a 32-bit library.  See also:

http://www.swox.com/gmp/manual/ABI-and-ISA.html#ABI-and-ISA

Subject: Re:  kinds.h not generated, causing failure

langton at gcc dot gnu dot org a écrit :
> ------- Comment #15 from langton at gcc dot gnu dot org  2006-06-20 23:32 -------
> (In reply to comment #14)
> 
>>GMP-4.2
>>./configure --prefix=/opt --with-gnu-ld --disable-cxx  --disable-nails 
>>--disable-mpfr
>>MPFR-2.2
>>./configure --enable-mpfr --with-gmp-=/opt --prefix=/opt --with-gmp-lib=/opt
>>--with-gmp-include=/opt && make -j2
>>
>>I think that both libraries are 32 bits libraries, not 64.
>>
>>GCC
>>../configure --prefix=/opt --enable-threads=posix
>>--enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld
>>--with-mpfr=/opt --disable-multilib && make -j2 bootstrap
>>
> 
> 
> Try adding ABI=32 to the GMP options.  I don't have a SPARC box, but on
> AIX-ppc, this was necessary to force GMP to build a 32-bit library.  See also:
> 
> http://www.swox.com/gmp/manual/ABI-and-ISA.html#ABI-and-ISA

	Thanks but it doesn't work...

stage1/xgcc -Bstage1/ -B/opt/sparc-sun-solaris2.9/bin/ -c   -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros 
-Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H 
-I. -Icp -I../../gcc -I../../gcc/cp -I../../gcc/../include -I./../intl 
-I../../gcc/../libcpp/include -I/opt/include    ../../gcc/cp/search.c -o 
cp/search.o
../../gcc/cp/search.c: In function 'dfs_dcast_hint_post':
../../gcc/cp/search.c:336: internal compiler error: Bus erroné
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [cp/search.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/bertrand/gcc-4.1.1/build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/home/bertrand/gcc-4.1.1/build/gcc'
make: *** [bootstrap] Error 2
lebegue:[~/gcc-4.1.1/build] >

	Regards,

	JKB

(In reply to comment #16)
> 
>         Thanks but it doesn't work...

Did you re-run 'configure' after rebuilding GMP and MPFR?  What happens if you try to configure and bootstrap from a clean object directory?

Re. comment #16: That looks like you get an internal compiler error (ICE )while building g++ which has nothing to do with libgfortran.  If that ICE is reproducible, it deserves its own bug report.

Closing as invalid as there have been no feedback in 3 months.

I'd like to reopen this bug, as I'm seeing it on sparc-sun-solaris2.8.  I have built the most recent GMP and MPFR versions and have the appropriate --with-gmp and --with-mpfr lines.  At first, MPFR wouldn't build because GMP built a 64-bit version, so I rebuilt GMP explicitly specifying sparc-sun-solaris2.8 as the build platform.  I use ksh.  From the failing build:

/bin/ksh /remote/atg5/jbuck/svn/4_2_branch/gcc/libgfortran/mk-kinds-h.sh '/remote/atg5/jbuck/sol2.tmp/./gcc/gfortran -B/remote/atg5/jbuck/sol2.tmp/./gcc/ -B/u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/bin/ -B/u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/lib/ -isystem /u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/include -isystem /u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h
/remote/atg5/jbuck/svn/4_2_branch/gcc/libgfortran/mk-kinds-h.sh: Unknown type
grep '^#' < kinds.h > kinds.inc
/bin/ksh: kinds.h: cannot open

(In reply to comment #20)
> I'd like to reopen this bug, as I'm seeing it on sparc-sun-solaris2.8.  I have
> built the most recent GMP and MPFR versions and have the appropriate --with-gmp
> and --with-mpfr lines.  At first, MPFR wouldn't build because GMP built a
> 64-bit version, so I rebuilt GMP explicitly specifying sparc-sun-solaris2.8 as
> the build platform. 

Did you run make -k check for both GMP and MPFR?  Some compiler versions are known to miscompile GMP which is most likely what is happening here.
This is not a bug still as 

*** This bug has been marked as a duplicate of 29866 ***

Slow down, please!  You don't need to set speed records for resolving bugs here.

My report is not a duplicate of the bug you tried to attach it to, because I did not use -j at all!

make -k check for gmp passes all tests.  Still checking on mpfr; in the meantime, it won't kill you to leave it open a bit more.

I went and rebuilt everything, ran into the problem again, and determined that it was because, although there was a correct --with-gmp, gfortran was failing because  gmp wasn't on LD_LIBRARY_PATH.  But gmp is now in the middle-end, right?  And libstdc++ successfully built with this flow, so the bug isn't encountered for hours on a slow Sparc with -j1.

Anyway, the Fortran library built and the compiler is now running tests.

Whether this one is a true bug is debatable.  It seems to me that every other GNU tool I try, as well as the rest of gcc, builds correctly when the location of a library is given with a --with flag, even if it isn't on LD_LIBRARY_PATH.  If this is the GNU standard way, then we have a real bug here.  If not, we need loud warnings in the installation instructions that --with-gmp does not suffice.

Subject: Re:  kinds.h not generated, causing failure

jbuck at gcc dot gnu dot org wrote:
> ------- Comment #23 from jbuck at gcc dot gnu dot org  2006-12-09 18:14 -------
> 
> Anyway, the Fortran library built and the compiler is now running tests.
> 
> Whether this one is a true bug is debatable.

Have you looked at /etc/ld.so.conf or equivalent on your system?  Usually 
LD_LIBRARY_PATH is needed if the library is not in one of your regular system 
library paths.  You could add it here as well.

For example on my system here:

$ ldd ./bin/gfc
         libgmp.so.3 => /usr/lib/libgmp.so.3 (0x0000003f9d400000)
         libc.so.6 => /lib64/libc.so.6 (0x0000003122800000)
         /lib64/ld-linux-x86-64.so.2 (0x0000003121800000)

Jerry: no, gmp isn't in the default path, which is why gcc was configured with --with-gmp and --with-mpfr flags.  On this particular machine I do not have root, and since it's used to build apps for legacy systems it has to keep running a rather old and unmodified version of Solaris.

The point is that different parts of gcc appear to be inconsistent about whether the --with-gmp flag is adequate, or whether an LD_LIBRARY_PATH setting is also needed.

As I said, I fixed the problem by setting LD_LIBRARY_PATH.  But I still have an issue over whether this should be required, given the --with-gmp setting and that the configure script detected gmp and even built and ran a test program.

Perhaps the gcc list is the best place to discuss this.

I would just like to say that I see this on sparc64-linux too on the 4.2 branch.

Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u:

binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
glibc-headers-2.5-3.1.sparc
gmp-2.4.1				(local build from gcc's infrastructure)
mpfr-2.2.1				(local build from gcc's infrastructure)
kernel-2.6.18-1.2798.al3.1.sparc64
libgcc-4.1.1-30.1.sparc
libgcc-4.1.1-30.1.sparc64
libgcj-4.1.1-30.1.sparc
libgcj-4.1.1-30.1.sparc64
libgcj-devel-4.1.1-30.1.sparc
libgcj-devel-4.1.1-30.1.sparc64
libstdc++-4.1.1-30.1.sparc
libstdc++-4.1.1-30.1.sparc64
libstdc++-devel-4.1.1-30.1.sparc
libstdc++-devel-4.1.1-30.1.sparc64
make-3.81-1.1.sparc
tcl-8.4.13-3.al3.sparc

LAST_UPDATED: Fri Dec 15 08:51:23 UTC 2006 (revision 119876)

configure: ../gcc/configure   --enable-__cxa_atexit --enable-shared --with-cpu=v7 --with-gmp=/usr/local/gmp-mpfr --with-mpfr=/usr/local/gmp-mpfr --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang

/bin/sh ../../../gcc/libgfortran/mk-kinds-h.sh '/usr/local/src/branch/objdir/./gcc/gfortran -B/usr/local/src/branch/objdir/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h
../../../gcc/libgfortran/mk-kinds-h.sh: Unknown type
grep '^#' < kinds.h > kinds.inc
/bin/sh: kinds.h: No such file or directory
make[2]: *** [kinds.inc] Error 1
make[2]: Leaving directory `/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/usr/local/src/branch/objdir'
make: *** [bootstrap] Error 2

> I would just like to say that I see this on sparc64-linux too on the 4.2
> branch.

Try to compile a Fortran source file with the compiler and see what happens.
Presumably wrong or missing libraries in LD_LIBRARY_PATH.

Yes, it seems that LD_LIBRARY_PATH is the cause of all the problems, but I also think it might not be a great idea to just say "not a bug, PEBKAC" (problem exists between keyboard and chair).  The issue is that the failure doesn't show up until an hour or more into a build run, and then the error message is completely obscure.  There is no direct indication that the cause is a gfortran failure to run.

Could configure be made to object if a simple program dynamically linked with libgmp and libmpfr won't run?  Then users will fix the problem before starting the build.

Alternatively, libgfortran/mk-sik-inc.sh could be changed to give a better
error message for the failure, but this has the problem that the user won't see the failure until a rather late point.

> Could configure be made to object if a simple program dynamically linked with
> libgmp and libmpfr won't run?  Then users will fix the problem before starting
> the build.

I think that the configure script should simply check that the Fortran
compiler works and abort if it doesn't.

(In reply to comment #29)
> I think that the configure script should simply check that the Fortran
> compiler works and abort if it doesn't.

Tentative patch to do just that is available at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00642.html

Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00659.html

Subject: Bug 26893

Author: fxcoudert
Date: Fri Jan 19 07:12:16 2007
New Revision: 120949

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120949
Log:
	PR libfortran/26893
	* acinclude.m4 (LIBGFOR_WORKING_GFORTRAN): New check.
	* configure.ac: Add call to LIBGFOR_WORKING_GFORTRAN.
	* configure: Regenerate.
	* config.h.in: Regenerate because it was forgottent in the last
	commit.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/acinclude.m4
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac

Subject: Bug 26893

Author: fxcoudert
Date: Sat Jan 20 15:55:41 2007
New Revision: 121001

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121001
Log:
	PR fortran/30446
	* options.c (gfc_handle_module_path_options): Path used in -J
	option is now added to the module search path.

	PR libfortran/26893
	* acinclude.m4 (LIBGFOR_WORKING_GFORTRAN): New check.
	* configure.ac: Add call to LIBGFOR_WORKING_GFORTRAN.
	* configure: Regenerate.
	* config.h.in: Regenerate because it was forgottent in the last
	commit.

Modified:
    branches/gcc-4_2-branch/gcc/fortran/ChangeLog
    branches/gcc-4_2-branch/gcc/fortran/options.c
    branches/gcc-4_2-branch/libgfortran/ChangeLog
    branches/gcc-4_2-branch/libgfortran/acinclude.m4
    branches/gcc-4_2-branch/libgfortran/configure
    branches/gcc-4_2-branch/libgfortran/configure.ac

Fixed on mainline and 4.2.