Re: gfortran FFLAGS without paths?
Thomas Weber <thomas.weber.mail@gmail.com> writes:
> Nothing that needs severeal lines of script code and a 100+ token long
> regexp :)
OK, just checking. :-)
> Yes, I saw that possibility later. Wouldn't
>
> fc_libs = "-lgfortranbegin -lgfortran"
>
> be enough, though?
Quite possibly; it depends on whether the relevant configure(.in)
logic intentionally runs with a non-empty LIBS setting.
> That's one of the things I'm unsure of. Will the above work, if I use
> e.g. g++-4.3 with gfortran-4.2? And if it doesn't work, will it at least
> break in a clear way?
My concern was that the set of appropriate -l specifications might
change in principle, but in practice you're absolutely right that ABI
changes are more of a concern. One way to guard against that,
assuming you require users to go through mkoctfile, would be to set
c_compiler=gcc-$(GCCMAJOR).$(GCCMINOR) and to do likewise for
cxx_compiler and f77_compiler, at which point you'd merely need
unversioned dependencies on the corresponding gcc-x.y packages.
(If you can't rely on that, you might need to resort to
gfortran -print-file-name=libgfortran.so | sed -e 's,\.[0-9]*\(/[^/]*\),\1,'
and likewise for libgfortranbegin.a.)
> I don't think Octave does anything special, it seems to use the default
> AC_F77_LIBRARY_LDFLAGS macro. The problem is not so much the test but
> the fact that later on, these values are used without being tested
> again.
Sure, I agree that the results are reasonable enough for immediate
use, just not robust in the face of intervening upgrades.
> Anyway, I just wanted to ensure that I don't start doing something
> entirely stupid, so thanks for your help.
No problem; glad to have been of help.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu
Reply to: