From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 42C093853804 for ; Fri, 18 Mar 2022 12:51:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42C093853804 Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-247-YK6LH8ZWMkiBPY-fMkafiQ-1; Fri, 18 Mar 2022 08:51:39 -0400 X-MC-Unique: YK6LH8ZWMkiBPY-fMkafiQ-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-2d7eaa730d9so70329287b3.13 for ; Fri, 18 Mar 2022 05:51:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=knhbZ18JWYkn+YZdpLcxzzqOw5JJ2+9drMs3ouhSV/M=; b=iKq0yYy2TqDUnB6NFQDMNTIDmxyeOuH0rA8DNQ8auEBC4SVdD3aR5ViSQULRFA/lXA mA18B6eeNneBCxNUawUGqdxe7qaY1KiMXXvbMZ29yyu8SJ3EhdMU5zCOQz/hO6rIQ1df WWaVZ3B2OvG2EE9nBbxh8dF1fxNmbp9AK51rgZKo29Or3CyXbXaRDvdzUjOq69wDAzjj jpuiSs1Ce8U0+SaX27XcmUzRBNgs5qP4ZZG/8Qp3yhnoFt941gtqPF0mW/beilr9Z7L1 xjgQD4oEXVCrG9e9dQIH0cmXjdBu2pazShzu2K/mNEV69tpsWhcY/YxwHvjJI5mb5fvz IVNw== X-Gm-Message-State: AOAM5325tlvHlaZ3BKaKnjd0QCpC6e0C8ONtSX67f4iVL6iNzHPMZyHQ IY7/WNR9aB6bFUNH21oLrde3Am25alZNo1WGP4v3PbuPr/6FIfm730+Ws+al5rFaHY19fFLBgeO uqVhpfqf1MhPMAAEEc+/VL5Qpl3+M6Ds= X-Received: by 2002:a0d:d7c3:0:b0:2e5:8fc6:ed98 with SMTP id z186-20020a0dd7c3000000b002e58fc6ed98mr11018009ywd.206.1647607899308; Fri, 18 Mar 2022 05:51:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVzRmW6fE2oBdIMUivOh4rPZiLgz+1ewKjxcIZ/2WwdRZphu2hClPuNV50VybIgNgmi07CKDQLWiONit3q6hg= X-Received: by 2002:a0d:d7c3:0:b0:2e5:8fc6:ed98 with SMTP id z186-20020a0dd7c3000000b002e58fc6ed98mr11017995ywd.206.1647607899141; Fri, 18 Mar 2022 05:51:39 -0700 (PDT) MIME-Version: 1.0 References: <20220316212453.243636-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Fri, 18 Mar 2022 12:51:28 +0000 Message-ID: Subject: Re: [committed] libstdc++: Fix symbol versioning for Solaris 11.3 [PR103407] To: Rainer Orth Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 12:51:42 -0000 On Fri, 18 Mar 2022 at 12:47, Rainer Orth wrote: > > Hi Jonathan, > > > I did some very brief testing and it seemed like a program linked to > > the Solaris 11.3 libstdc++.so.6.0.30 (with from_chars@GLIBCXX_3.4.30) > > can still run against libstdc++.so.6.0.30 with > > from_chars@GLIBCXX_3.4.29 (which should match what you get on Solaris > > 11.4 if I correctly fiddled with the versioning). So I don't > > indeed. You can observe the symbols provided and consumed by shared > objects and executables with pvs. > > E.g. on 11.4: > > $ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R > libstdc++.so - GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RfSt12chars_format; > libstdc++.so - GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_ReSt12chars_format; > libstdc++.so - GLIBCXX_3.4.29: _ZSt10from_charsPKcS0_RdSt12chars_format; > > for the provider side vs. 11.3: > > $ pvs -dsvo libstdc++.so|grep _ZSt10from_charsPKcS0_R > libstdc++.so - GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_ReSt12chars_format; > libstdc++.so - GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RdSt12chars_format; > libstdc++.so - GLIBCXX_3.4.30: _ZSt10from_charsPKcS0_RfSt12chars_format; > > pvs -r shows symbols and versions required by an executable. > > > understand how the Solaris runtime linker handles symbol versions, but > > it seems like there's no backwards compatibility problem for the > > Solaris 11.4 build of libstdc++.so.6.0.30. > > You can observe this at runtime with LD_DEBUG=versions or > versions,detail. LD_DEBUG=help gives the full info. > > IIRC Solaris ld.so.1 just checks if the versions required by an > executable are provided by a shared object, but doesn't look into > individual symbols in advance. It may well be that some checks have > been relaxed in the 11.4 timeframe, though. Ah that would explain it. The libstdc++.so built on Solaris 11.4 has the std::from_chars symbols and it has version GLIBCXX_3.4.30, so that satisfies the requirements for a program linked against the libstdc++.so on Solaris 11.3.