This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
"Why does my libgfortran build yield an error on kinds.h?"
- From: FX Coudert <fxcoudert at gmail dot com>
- To: Bernhard Fischer <rep dot nop at aon dot at>
- Cc: "fortran at gcc dot gnu dot org List" <fortran at gcc dot gnu dot org>
- Date: Sun, 21 Jan 2007 14:03:26 +0100
- Subject: "Why does my libgfortran build yield an error on kinds.h?"
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=GMGA5yz8GS4w1ca1K6I1t9yLYoKlsR4UVtRqIKkISk8VMU4mcuJY/xedY5/83Om3Q7P55t8JYXXeFfO0pglqfkOvnB3MFNFlB/L9wk9XFdQBSDNsI3jHKSS3QDCDy6CJh/RolcKSTOSDcZilkb8z8JBRLf8VVjPywmPd6j0DN0M=
Hi Bernhard, hi all,
[ I first wrote this message to Bernhard, and thought it was a nice
summary of the cases where we get an error while building libgfortran/
kinds.h, so I send it to the list, with hopefully enough context for
everyone to understand ]
I read the busybox thread you mentionned to me (http://busybox.net/
bugs/view.php?id=1164). I'm not sure this is a problem with
autodetecting kinds... in fact, what I can say for sure is that every
single time this exact error was reported by someone, it was simply a
problem of the newly built gfortran compiler not working at all. The
most common reasons for that have been:
- the f951 binary being linked to the shared mpfr library (or
gmp), and LD_LIBRARY_PATH not being set so that running the compiler
simply errors out because of the shared library not being found;
- the f951 binary being linked to GMP and MPFR libraries built for
a different architecture than the *host* architecture (ie the one the
compiler is executed on): including, but not limited to, 64bit GMP
and/or MPFR libraries used in a 32bit compiler binary;
- the f951 binary being unable to run on the host, e.g.
segfaulting every time it's called, because it's compiled with a
bizarre -march value that doesn't match the host architecture.
I've recently (yesterday) commited a patch that explcitly checks if
the compiler is working and gives a better error message. Right now,
the best way for you to determine what's going wrong is to use the
compiler indicated in the mk-kinds-h.sh command line (the failing
one) to build a small test program. For example, when the failing
command-line is:
/bin/sh /root/buildroot/toolchain_build_i686/gcc-4.2-20070110/
libgfortran/mk-kinds-h.sh '/root/buildroot/toolchain_build_i686/
gcc-4.2-final/./gcc/gfortran -B/root/buildroot/toolchain_build_i686/
gcc-4.2-final/./gcc/ -B/root/buildroot/build_i686/staging_dir/i686-
linux-uclibc/bin/ -B/root/buildroot/build_i686/staging_dir/i686-
linux-uclibc/lib/ -isystem /root/buildroot/build_i686/staging_dir/
i686-linux-uclibc/include -isystem /root/buildroot/build_i686/
staging_dir/i686-linux-uclibc/sys-include -I . -Wall -fno-repack-
arrays -fno-underscoring ' > kinds.h || rm kinds.h
the compiler command is the first arg of mk-kinds-h.sh, that is:
/root/buildroot/toolchain_build_i686/gcc-4.2-final/./gcc/gfortran -
B/root/buildroot/toolchain_build_i686/gcc-4.2-final/./gcc/ -B/root/
buildroot/build_i686/staging_dir/i686-linux-uclibc/bin/ -B/root/
buildroot/build_i686/staging_dir/i686-linux-uclibc/lib/ -isystem /
root/buildroot/build_i686/staging_dir/i686-linux-uclibc/include -
isystem /root/buildroot/build_i686/staging_dir/i686-linux-uclibc/
sys-include -I . -Wall -fno-repack-arrays -fno-underscoring
Create a small test.f90 file, containing simply
integer :: i
end
and try compiling it ("large-command-line -c test.f90") and see what
the compiler says. If you have a version of gfortran more recent than
my patch, it gives the name of log file that you can look into: it
will contain the error message from the compiler.
Now, I hope that we can refer people to this post in the future!
FX