[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Coinstallability of Fortran libraries built with different compilers



On 2011-10-23 08:45, Enrico Zini wrote:
On Sat, Oct 22, 2011 at 04:24:23PM -0700, Steve Langasek wrote:

One point to think of is how this works with multiarch, which is
being introduced in Debian. Instead of 'ifort' should we use the
architecture triplet, eg. i386-linux-intel instead ?
Then the libraries go in i386-linux-intel rather than i386-linux-gnu
for gfortran; ditto for the .mod files in
/usr/include/i386-linux-intel
i386-linux-intel does not yet officially exist. Where are the triplets specified? I was using this as an example. Similar issues exist with other (proprietary) compilers.
I'm not familiar with this i386-linux-intel triplet.  Is this a triplet
targeted by the toolchain?  Does software built for this target not use GNU
libc?  (I guess I can't presume that it uses any libc at all, since we're
speaking specifically of fortran here.)
I'm not sure about libc dependencies of fortran binaries, I'll leave
Alastair to answer that bit. My understanding on library use and ABI
compatibilities is that the critical point are .mod files in
/usr/include, whereas .a or .so files are perfectly reusable across
compilers.
Yes, the problem is that .mod files are architecture and compiler dependent. Hence it is important that the discovery path for them is not arch. and compiler dependent too: e.g. pkg-config needs to be used accordingly to discover the appropriate path (use pkg-config --variable=fflags rather than --cflags, which returns -I or -M for the appropriate
compiler, for the appropriate path).

I believe that, as of current versions, intel compilers icc and ifort generate .a and .so files that are perfectly reusable. This has not been guaranteed with compiler and version, though: some have (had) incompatible extensions so that while they link with GNU libc, the reverse was is not true.

This is similar in concept to i386 / amd64 only being backward compatible, etc. Hence the usefulness
of the multiarch concept in this case.
That means that fortran binaries compiled with any compiler are free to
depend on C libraries built with any compiler. For example,
/usr/lib/libnetcdff.so links with curl, libm, libc, libhdf5, and plenty
others according to ldd. Ideally one would want to have parallel,
per-compiler versions of fortran libraries, because of the different
.mod file formats, and then share all the chain of C dependencies.


Ciao,

Enrico



--
Alastair McKinstry  ,<alastair@sceal.ie>  ,<mckinstry@debian.org>     http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.



Reply to: