From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C41193857007; Wed,  8 Mar 2023 09:28:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C41193857007
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678267688;
	bh=RpwLusIT0v5NJRjOIU2SFUi0NdI8QKk1SrxV/0wWgYQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=J/Ruy5GzHSdCO4deL1kfTVIg3d0jT+sYccsnNya0fQntSNmpthZpzRFr4yZSBklSK
	 sKjgH3VRzaRMGFN6AcwfyrV1/TrDtJDa1qjHDVaGipWaEHM1l/NS3XKbY4rFa8mtwR
	 zXjIQVretdvTn+dJt3DAKab4dta6c3Y7YT1K0xws=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/108969] [13 Regression] Initializing iostreams in the
 library needs a GLIBCXX_3.4.31 versioned symbol
Date: Wed, 08 Mar 2023 09:28:08 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ABI
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108969-4-x4lLvkr2Yy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108969-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108969-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108969

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> then shouldn't the
> solution be that programs using streams and compiled with GCC 13 require
> a symbol with a version newer than 6.0.30 (or even not present in the
> oder DSOs) so the dynamic link will fail?


I believe that is what we're discussing here, how to arrange that such symb=
ols
would be
those mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108969#c7
That solution doesn't work everywhere, because only GNU symbol versioning
allows the
same symbol to be exported at multiple symbol versions.
So, for Solaris we can just not do anything, or come up with some other
solution
(like the artificial use of a symbol through asm in the header file).=