FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-21-2011, 09:28 AM
Alastair McKinstry
 
Default Coinstallability of Fortran libraries built with different compilers

Cross-posting this to debian-devel for greater visibility on multiarch,

On 2011-10-20 17:30, Enrico Zini wrote:

Hello,

another issue caused by a lack of standards for Fortran .mod files is
that one cannot use, say, gfortran, to link to a library built with
another compiler like ifort.

We are starting to need to install development systems that would allow
both a gfortran toolchain and an ifort toolchain. That would mean having
to compile all libraries twice, and installing them twice in the system.

I have been experimenting with hacks like installing gfortran files in
/usr/include and /usr/lib and ifort files in /usr/include/ifort and
/usr/lib/ifort, and with a bit of insisting, things can be made to work.

That has also the nice property that standard Debian packages, that are
built with gfortran, fit normally in the system.

Is that a solution as good as anything, or are you doing something
better?

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

I'd avoid /usr/include/ifort as it looks too much like a subdirectory
used by package ifort,

rather than somewhere netcdf would expect to find its stuff, etc.

Following the multiarch pattern means we can use pkg-config correctly
for Intel compilers;
e.g. /usr/lib/i386-linux-intel/pkgconfig contains the .pc files for the
Intel versions;
we can either then set the PKG_CONFIG_PATH or use the 'cross-compiler
pkgconfig'

to get pkg-config to Do The Right Thing.

Regards
Alastair



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.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA13B20.7060704@sceal.ie">http://lists.debian.org/4EA13B20.7060704@sceal.ie
 
Old 10-22-2011, 11:24 PM
Steve Langasek
 
Default Coinstallability of Fortran libraries built with different compilers

Hi Alastair,

On Fri, Oct 21, 2011 at 10:28:00AM +0100, Alastair McKinstry wrote:
> Cross-posting this to debian-devel for greater visibility on multiarch,

> On 2011-10-20 17:30, Enrico Zini wrote:
> >another issue caused by a lack of standards for Fortran .mod files is
> >that one cannot use, say, gfortran, to link to a library built with
> >another compiler like ifort.

> >We are starting to need to install development systems that would allow
> >both a gfortran toolchain and an ifort toolchain. That would mean having
> >to compile all libraries twice, and installing them twice in the system.

> >I have been experimenting with hacks like installing gfortran files in
> >/usr/include and /usr/lib and ifort files in /usr/include/ifort and
> >/usr/lib/ifort, and with a bit of insisting, things can be made to work.

> >That has also the nice property that standard Debian packages, that are
> >built with gfortran, fit normally in the system.

> >Is that a solution as good as anything, or are you doing something
> >better?

> 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

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.)

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 10-23-2011, 07:40 AM
Josselin Mouette
 
Default Coinstallability of Fortran libraries built with different compilers

Le samedi 22 octobre 2011 à 16:24 -0700, Steve Langasek a écrit :
> > 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
>
> 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.)

It uses the same libc, but it uses a different Fortran library.

Because of that library, you can link Fortran libraries and programs
only against other Fortran libraries built with the same compiler. The
architecture triplet would be the same, but it would need an addition
for the Fortran library.

IIRC the problem used to be the same with C++ until the libstdc++ ABI
was standardized.

--
.'`. Josselin Mouette
: :' :
`. `'
`-
 
Old 10-23-2011, 07:45 AM
Enrico Zini
 
Default Coinstallability of Fortran libraries built with different compilers

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
>
> 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.

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

--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
 
Old 10-23-2011, 09:22 AM
Alastair McKinstry
 
Default 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.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EA3DCE2.8020609@sceal.ie">http://lists.debian.org/4EA3DCE2.8020609@sceal.ie
 
Old 10-23-2011, 09:23 AM
Enrico Zini
 
Default Coinstallability of Fortran libraries built with different compilers

On Sun, Oct 23, 2011 at 09:45:06AM +0200, Enrico Zini wrote:

> 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.

I stand corrected: when .a or .so binary compatibility happen, it is by
luck: http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_Fortran
although, according to that explanation, call name mangling seems to be
standardising somehow.


Ciao,

Enrico

--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
 
Old 10-23-2011, 12:35 PM
Simon McVittie
 
Default Coinstallability of Fortran libraries built with different compilers

On Sun, 23 Oct 2011 at 10:22:42 +0100, Alastair McKinstry wrote:
> i386-linux-intel does not yet officially exist. Where are the
> triplets specified?

GNU configuration types are specified by GNU config.sub and config.guess
(distributed with autoconf, but they have their own upstream git repository).
The canonical form is CPU-MANUFACTURER-OS or CPU-MANUFACTURER-KERNEL-OS
(arm-unknown-linux-gnu, powerpc-apple-darwin1.3, sparc-sun-solaris2)
but the manufacturer part is hardly ever relevant to the ABI, so
cross-compiler prefixes, toolchain directories and multiarch tuples omit it.
On Linux the manufacturer part is typically "unknown" anyway.

The Intel vs. GNU Fortran compiler is a smaller difference than the GNU
triplets normally encode: when a GNU tuple says "i386-linux-gnu" or
"i386-kfreebsd-gnu", the "gnu" part refers to the GNU operating system
(mainly the use of glibc as the C library, but to some extent also things
like coreutils).

The C++ ABI transitions we've had in the last few years (e.g. libarts1 to
libarts1c2 to libarts1c2a) didn't affect the GNU tuple either.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111023123526.GA16209@reptile.pseudorandom.co.uk" >http://lists.debian.org/20111023123526.GA16209@reptile.pseudorandom.co.uk
 
Old 10-23-2011, 03:09 PM
Steve Langasek
 
Default Coinstallability of Fortran libraries built with different compilers

On Sun, Oct 23, 2011 at 09:40:47AM +0200, Josselin Mouette wrote:
> Le samedi 22 octobre 2011 à 16:24 -0700, Steve Langasek a écrit :
> > > 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

> > 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.)

> It uses the same libc, but it uses a different Fortran library.

> Because of that library, you can link Fortran libraries and programs
> only against other Fortran libraries built with the same compiler. The
> architecture triplet would be the same, but it would need an addition
> for the Fortran library.

Ok; it doesn't sound like multiarch is a good fit for this then,
unfortunately.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 

Thread Tools




All times are GMT. The time now is 11:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org