Thomas Weber <[email protected]> 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/[email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
