From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123420 invoked by alias); 12 Mar 2018 17:05:03 -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 123409 invoked by uid 89); 12 Mar 2018 17:05:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=on-going, competitive, love X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 17:05:01 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w2CH4xGJ061881 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 10:04:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w2CH4wUN061880; Mon, 12 Mar 2018 10:04:58 -0700 (PDT) (envelope-from sgk) Date: Mon, 12 Mar 2018 17:05:00 -0000 From: Steve Kargl To: Dave Love Cc: fortran@gcc.gnu.org Subject: Re: backwards incompatibility Message-ID: <20180312170458.GA61632@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <871sgp8fpb.fsf@albion.it.manchester.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871sgp8fpb.fsf@albion.it.manchester.ac.uk> User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00045.txt.bz2 On Mon, Mar 12, 2018 at 03:40:48PM +0000, Dave Love wrote: > It's quite a pain for supporting research systems that the gfortran > module format changes incompatibly with every (?) new version. For > instance, you can't mix development packages built with the RHEL system > compiler with the more recent "devtoolset" compiler needed for hardware > support. As far as I know, the proprietary compilers don't have the > same issue. I can't find anything written about that, but I haven't > tried to understand the implementation. Is there something written? > Otherwise, is it feasible to convert older module files to newer > formats, given that the ABI doesn't change, as I've seen in release > notes (and would hope)? If so, where would one look in the code to see > about doing so? > > Version 8 makes the situation worse by breaking run time compatibility, > not just build-time, with a different libgfortran shared library > version. That already caused considerable disruption with Fedora > packaging after the switch to GCC 8. With ELF, can't you use versioned > symbols to avoid a new soname, like libgcc and libgomp do? > > Regardless of any annoyances, thanks for keeping a competitive free > compiler going! 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. 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). -- Steve