From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40481 invoked by alias); 12 Mar 2018 20:42:50 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 35033 invoked by uid 89); 12 Mar 2018 20:42:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.2 spammy=on-going, Hx-languages-length:1506 X-HELO: serenity.mcc.ac.uk Received: from serenity.mcc.ac.uk (HELO serenity.mcc.ac.uk) (130.88.200.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 20:42:46 +0000 Received: from asmtp2.its.manchester.ac.uk ([130.88.13.150]) by serenity.mcc.ac.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1evUHL-000Cva-GE; Mon, 12 Mar 2018 20:42:43 +0000 Received: from [10.247.128.2] (port=46286 helo=albion.it.manchester.ac.uk) by asmtp2.its.manchester.ac.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1evUHL-0007XR-7W; Mon, 12 Mar 2018 20:42:43 +0000 From: Dave Love To: Steve Kargl Cc: Subject: Re: backwards incompatibility References: <871sgp8fpb.fsf@albion.it.manchester.ac.uk> <20180312170458.GA61632@troutmask.apl.washington.edu> X-Draft-From: ("Misc" 5392) Date: Mon, 12 Mar 2018 20:42:00 -0000 In-Reply-To: <20180312170458.GA61632@troutmask.apl.washington.edu> (Steve Kargl's message of "Mon, 12 Mar 2018 10:04:58 -0700") Message-ID: <87tvtl6n5p.fsf@albion.it.manchester.ac.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-From: Dave.Love@manchester.ac.uk X-SA-Exim-Connect-IP: 130.88.13.150 X-SA-Exim-Mail-From: dave.love@manchester.ac.uk X-SA-Exim-Scanned: No (on serenity.mcc.ac.uk); SAEximRunCond expanded to false X-Spam-Score: -5.0(?) X-SW-Source: 2018-03/txt/msg00048.txt.bz2 Steve Kargl writes: > Hi Dave, > > While I do not speak for the other contributors, I can > assure you that we take breaking the library ABI quite > serious. We maintain a list of changes that we know will > cause problems. If a change occurs that breaks the ABI, > we try to merge as many changes from the list as possible > to minimize on-going breakage. See > > https://gcc.gnu.org/wiki/LibgfortranAbiCleanup > > for those that have yet to be merged/fixed. Unfortunately, > the addition of user defined derived type IO, which was a > much requested feature, required a change to the library > internals for the upcoming 8.0. Yes, sure. I'm interested in whether there's something fundamental that prevents symbol versioning keeping backwards compatibility, or if it's basically a question of effort. There's a related question about what happens if you try to link code from, say gfortran 6 and 8. (I forgot or missed that there was a break at 7 too.) Is it expected to work, fail to link, or potentially fail mysteriously at run time? > Maintaining the internals of *.mod files is even more difficult > as changes are sometimes required for bug fixes as well as when > new features are implemented (e.g., parameterized derived type). Similarly, I'm wondering whether it should at least be possible to write a translator from an old version to a new one if someone worked on it, or whether that can't work. Thanks for any insight.