From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90386 invoked by alias); 12 Mar 2018 15:40:54 -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 90372 invoked by uid 89); 12 Mar 2018 15:40:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:4.85, competitive, research X-HELO: clarity.mcc.ac.uk Received: from clarity.mcc.ac.uk (HELO clarity.mcc.ac.uk) (130.88.200.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 15:40:51 +0000 Received: from asmtp1.its.manchester.ac.uk ([130.88.13.149]) by clarity.mcc.ac.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1evPZA-00074e-Ut for fortran@gcc.gnu.org; Mon, 12 Mar 2018 15:40:49 +0000 Received: from [10.247.128.2] (port=45656 helo=albion.it.manchester.ac.uk) by asmtp1.its.manchester.ac.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1evPZA-00023t-MG for fortran@gcc.gnu.org; Mon, 12 Mar 2018 15:40:48 +0000 From: Dave Love To: fortran@gcc.gnu.org Subject: backwards incompatibility Date: Mon, 12 Mar 2018 15:40:00 -0000 Message-ID: <871sgp8fpb.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.149 X-SA-Exim-Mail-From: dave.love@manchester.ac.uk X-SA-Exim-Scanned: No (on clarity.mcc.ac.uk); SAEximRunCond expanded to false X-Spam-Score: -5.0(?) X-SW-Source: 2018-03/txt/msg00043.txt.bz2 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!