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 ,<alast...@sceal.ie> ,<mckins...@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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ea3dce2.8020...@sceal.ie
