public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dave Love <dave.love@manchester.ac.uk>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: <fortran@gcc.gnu.org>
Subject: Re: backwards incompatibility
Date: Tue, 13 Mar 2018 15:14:00 -0000	[thread overview]
Message-ID: <87zi3c57o8.fsf@albion.it.manchester.ac.uk> (raw)
In-Reply-To: <b3b5e116-7b98-0514-6bc9-a4a6e8be5b93@netcologne.de> (Thomas	Koenig's message of "Mon, 12 Mar 2018 22:17:56 +0100")

Thomas Koenig <tkoenig@netcologne.de> writes:

> Hi Dave,
>
>> It's quite a pain for supporting research systems that the gfortran
>> module format changes incompatibly with every (?) new version.
>
> A lot of releases, yes. The problem is that we use a lot of positional
> parameters in the files.
>
> I have given a little thought of how to get around that by using some
> sort of keyword-value scheme, which by definition are almost infinitely
> extensible.
>
> Another possibility would be to write out INTERFACE blocks as *.mod
> files, which could then be re-read and re-parsed.
>
> Just two problems: To a) get the design right, and b) get the
> implementation right.  This would take a lot of effort, and the
> manpower simplfy isn't there (and it hasn't figured high on the
> list of priorities).
>
> Of course, volunteers are always welcome.

The immediate interest is in whether it's possible to write translations
of old .mods to newer formats to solve the existing issues, but that
presumably only makes sense if you can reliably mix code compiled with
old and new compiler versions.  I'll see how far I can get with module.c
when I have a chance, thanks.

>> Version 8 makes the situation worse by breaking run time compatibility,
>> not just build-time, with a different libgfortran shared library
>> version.
>
> This had to be done in order to fix long-standing bugs, and to allow
> Fortran 2008 compliance.  We tried to stuff as much as possible into
> this release, to avoid breaking binary compatibility for as many
> releases as possible.

Sure, I understand the need for mods of some sort.

>> That already caused considerable disruption with Fedora
>> packaging after the switch to GCC 8.
>
> What's the problem? Shipping two versions of shared libraries together
> cannot be that hard, can it? OpenSUSE tumbleweed, which already
> ships a pre-gcc8, manages this fine.

Yes, I have libgfortran.3 and .4 in RHEL, but it's not clear I can
(reliably) link libraries which require both of them in the same binary.
I suppose I should at least pull out abidiff.

>> With ELF, can't you use versioned
>> symbols to avoid a new soname, like libgcc and libgomp do?
>
> There are other systems which command equal attention - AIX, cygwin,
> MacOS. Of course, volunteers are always welcome...

I'm surprised AIX commands equal attention to GNU/Linux, but you have
ELF versioning anyway.  It's just not clear how libgfortran is different
from libstdc++ or libgomp and whether there are considerations past the
library ABI.

I hope it doesn't look as if I'm just moaning.  I might be able to do
some work, and I have some (very old) history with GNU Fortran.  I was
asking because I'd guess just reading source isn't good enough to
understand.

  reply	other threads:[~2018-03-13 15:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12 15:40 Dave Love
2018-03-12 17:05 ` Steve Kargl
2018-03-12 20:42   ` Dave Love
2018-03-12 21:18 ` Thomas Koenig
2018-03-13 15:14   ` Dave Love [this message]
2018-03-14  2:31     ` Jerry DeLisle
2018-03-16 13:48       ` Dave Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zi3c57o8.fsf@albion.it.manchester.ac.uk \
    --to=dave.love@manchester.ac.uk \
    --cc=fortran@gcc.gnu.org \
    --cc=tkoenig@netcologne.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).