On 11/19/2010 03:41 PM, Rainer Orth wrote:
Tobias Burnus<bur...@net-b.de> writes:
No, finding libgfortran.spec at compile time works - it is all about
finding it at run time.
pardon me: AFAIK the spec files are *only* used by the compiler driver,
not at runtime of the resulting executables.
Well, the spec files are used only by the driver - and neither by the
proper compiler (f951, cc1, etc.) nor by the generated executable.
However, besides the compiled in files, the driver also reads spec files
when it is run. That happens, e.g., for linking OpenMP (-fopenmp) or
since the addition of libquadmath for running "gfortran". See your self:
Run:
echo "end" > test.f90
gfortran -v -fopenmp test.f90 2>&1 |grep -i spec
On my system that gives:
Using built-in specs.
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgfortran.spec
rename spec lib to liborig
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgomp.spec
[Side note: See the /lib/ instead of /lib64/? That's the driver bug I am
talking about.]
And the compiler driver ("gfortran") needs to find the libgfortran.spec
file - otherwise, it simply aborts with an error message. As the
compiler might not be installed, if one runs the test suite, the .spec
file needs to be found by the compiler, e.g., by adding -L<directory> to
the .spec file.
No, they are not: LD_LIBRARY_PATH is only relevant for finding shared
objects at runtime and completely irrelevant to the compiler driver's
search for .spec files.
Well, the LD_LIBRARY_PATH is not wrong because of the .spec file itself.
However, it is seemingly wrong because of a side effect in the patch
makes sure that the .spec file is found -- or because something goes
wrong with finding libquadmath. In any case, without the patch
"gfortran" simply aborts - that the LD_LIBRARY_PATH is correct, does not
help then.
The changes made can be shown via:
svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp
> From a quick look, there seem to be several problems:
* libquadmath/.libs is added with -L and to LD_LIBRARY_PATH both if
libquadmath.a and again if libquadmath.${shlib_ext} exist. This would
explain why we see the unnecessary doubling of libquadmath/.libs in
LD_LIBRARY_PATH.
Granted. Though, shouldn't that also occur for libgfortran.*? Those
lines are copied from above.
* Unfortunately, this doesn't take the multilib subdir into account,
which is wrong for the non-default multilib.
I am not sure how it works for libgfortran (in the lines before
libquadmath). But as written, in terms of the .spec file there is also a
bug with regards to the driver, which I would like to fix first before
looking at the issues in gcc/testsuite/lib.
Tobias
