backwards incompatibility
Dave Love
dave.love@manchester.ac.uk
Tue Mar 13 15:14:00 GMT 2018
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.
More information about the Fortran
mailing list