From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fw@deneb.enyo.de>
Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21])
 by sourceware.org (Postfix) with ESMTPS id B3A013858402;
 Sun, 10 Oct 2021 16:14:45 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B3A013858402
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=deneb.enyo.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de
Received: from [172.17.203.2] (port=43419 helo=deneb.enyo.de)
 by albireo.enyo.de ([172.17.140.2]) with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 id 1mZbTH-0007Ne-10; Sun, 10 Oct 2021 16:14:43 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.94.2)
 (envelope-from <fw@deneb.enyo.de>)
 id 1mZbTG-00086L-Nv; Sun, 10 Oct 2021 18:14:42 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Thomas Koenig via Fortran <fortran@gcc.gnu.org>,  Jakub Jelinek
 <jakub@redhat.com>,  GCC Development <gcc@gcc.gnu.org>,  Paul Thomas
 <pault@gcc.gnu.org>,  Iain Sandoe <idsandoe@googlemail.com>,  Segher
 Boessenkool <segher@kernel.crashing.org>,  Thomas Koenig
 <tkoenig@netcologne.de>,  Tobias Burnus <tobias@codesourcery.com>
Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
References: <20211004100754.GL304296@tucnak>
 <YV5rGhDBjX3IxMlX@toto.the-meissners.org>
 <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de>
 <YV8RMwrw5Xa7Z2dm@toto.the-meissners.org>
 <20211007153306.GY304296@tucnak>
 <5533983c-f4d2-5041-75c9-9287e4e31f10@netcologne.de>
 <749ABCA1-5C3B-4EB8-8E4F-9B967A67AB07@googlemail.com>
 <334901cf-72b6-d1d7-dae6-3ec45170cf95@netcologne.de>
 <FF8235BA-2349-4A53-8B74-5EC5BB9BDDD9@googlemail.com>
 <e6004e4f-ed78-9e0b-8b84-6782d28c2338@netcologne.de>
 <87r1cuhcbp.fsf@linux-m68k.org>
Date: Sun, 10 Oct 2021 18:14:42 +0200
In-Reply-To: <87r1cuhcbp.fsf@linux-m68k.org> (Andreas Schwab's message of
 "Sat, 09 Oct 2021 09:44:26 +0200")
Message-ID: <874k9ozwjx.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Oct 2021 16:14:46 -0000

* Andreas Schwab:

> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled against different
> versions of glibc, you are in for surprises, too.  This isn't something
> new.  There is no guarantee of API stability.

This is of course true, but we nevertheless try to accommodate
existing static linking patterns with glibc if possible.  Maybe those
are more common with Fortran?  Then more compatibility for static
linking could be pretty much required there.  (I don't know enough
about Fortran to judge that.)