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.133.124]) by sourceware.org (Postfix) with ESMTPS id 22AF83856DC4 for ; Thu, 21 Apr 2022 10:15:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 22AF83856DC4 Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-RtlNV7rTP6y7X3tieRZcJg-1; Thu, 21 Apr 2022 06:15:49 -0400 X-MC-Unique: RtlNV7rTP6y7X3tieRZcJg-1 Received: by mail-yb1-f200.google.com with SMTP id r5-20020a258285000000b0064577f2c8adso833684ybk.21 for ; Thu, 21 Apr 2022 03:15:49 -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:content-transfer-encoding; bh=nAENjKcDiNsgrSC9Hzl4THDzyWLDkwly52n6cOezghA=; b=dkmVp3clsV2XrqP8m0TkgLRrbeYvSySPbV+WU7B7jcY2YNIwEqnzS9YRZCICi1TQUW 64x5fySyyb7CUY21gFhx4pED9hVoz16kRFkeSuyXvsbjRf7oRWodGkPu+L7bP/LxWfkS A2tJ3HMRwV3ofjRqT6piPkVepUFtxIYW6AddijaIyqtIgXw0ZJHkGsBWxqe9Mfv9pSMx +KTx5/JftVSyx3I6JbHhWFe4d5C9t+amgfevdWMKd3FMSZnI/5x52n/MKkZfdCcUuWG0 ZjfEUkKBo6nxn1flqRvK8olRM80uirRIwfxLZ2PTZ81WG9pLBNhQY7Ao5ukjHHbRIfSK ckpA== X-Gm-Message-State: AOAM530rWXljxGrzKUyxS6vrEeCgBOXfX+rBmbLqDHIlwEiS2rq7LQQa 1PemXLG+Fa+7j9IZ6wVpu38LjFart42Yw+rrHAPFwdMP+K8RAnZnXbQ7ZqVYPV8ykiM0Z4FuWXs f0ozVO3zJe7JzN1LQREa5Wq41hJC2KUU= X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr22847168ybs.365.1650536149155; Thu, 21 Apr 2022 03:15:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzP6vyzDtmh6GK8mFirie20RCDTJd9ushf9OpxsuFMlSGv5PzKSf0LEEfZCBR4F7OZqZ8eMKDj8uzO0iu+usd8= X-Received: by 2002:a05:6902:352:b0:63e:94c:883c with SMTP id e18-20020a056902035200b0063e094c883cmr22847151ybs.365.1650536148936; Thu, 21 Apr 2022 03:15:48 -0700 (PDT) MIME-Version: 1.0 References: <20220413142359.577396-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 21 Apr 2022 11:15:37 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602] To: Yubin Ruan Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: 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: Thu, 21 Apr 2022 10:15:52 -0000 On Thu, 21 Apr 2022 at 11:14, Yubin Ruan wrote: > > Hi, > > Will this be in GCC12? Unless the patch gets reverted, yes. GCC 12 hasn't branched from trunk yet, so everything on trunk will be in GCC 12. > > -- > Yubin > > On Wed, Apr 20, 2022 at 8:58 PM Jonathan Wakely via Libstdc++ > wrote: > > > > Pushed to trunk now. > > > > On Wed, 13 Apr 2022 at 15:24, Jonathan Wakely via Libstdc++ > > wrote: > > > > > > Tested x86_64-linux, without libiconv installed, with libiconv instal= led, > > > with libiconv installed but using an in-tree libiconv, with libiconv.= a > > > installed and using --with-libiconv-type=3Dstatic, and with libiconv.= so > > > installed and using --without-libiconv-prefix (which still fails). > > > > > > I'm not entirely happy about the fact that libtool's LTLIBICONV adds = an > > > rpath to libstdc++.so, but that can be avoided (as documented by this > > > patch) and I don't really see a better solution. Another option would= be > > > to use -l:libiconv.a if configure defines LTLIBICONV to non-empty and > > > the linker supports it, which would *force* the use of a static lib. = But > > > that seems unnecessarily hostile; not all users will dislike the rpat= h > > > solution. The proposed patch makes it Just Work=E2=84=A2 for users wh= o (for > > > whatever reason) have installed libiconv, while also allowing them to= do > > > something more sensible if they care enough to do so. > > > > > > Thoughts? > > > > > > -- >8 -- > > > > > > This fixes missing libiconv symbols when libstdc++ is built on a syst= em > > > that has libiconv installed. If the libiconv headers are found then > > > libstdc++ depends on libiconv_open etc instead of libc's iconv_open. = But > > > without this fix libstdc++ is not linked to the libiconv library that > > > provides the definitions of those symbols. > > > > > > As discussed in PR 93602 this changed means that libstdc++.so.6 might > > > have an rpath pointing to the location of the libiconv.so library. If > > > that is not desired, then GCC must be configured to link to a static > > > libiconv.a instead, using either --with-libiconv-type=3Dstatic or an > > > in-tree build of libiconv. > > > > > > libstdc++-v3/ChangeLog: > > > > > > PR libstdc++/93602 > > > * doc/xml/manual/prerequisites.xml: Document libiconv > > > workarounds. > > > * doc/html/manual/setup.html: Regenerate. > > > * src/Makefile.am (CXXLINK): Add $(LTLIBICONV). > > > * src/Makefile.in: Regenerate. > > > --- > > > diff --git a/libstdc++-v3/doc/xml/manual/prerequisites.xml b/libstdc+= +-v3/doc/xml/manual/prerequisites.xml > > > index 22e90a7e79d..8799487c821 100644 > > > --- a/libstdc++-v3/doc/xml/manual/prerequisites.xml > > > +++ b/libstdc++-v3/doc/xml/manual/prerequisites.xml > > > @@ -48,6 +48,56 @@ > > > > > > linux > > > > > > + > > > + > > > + The 'gnu' locale model makes use of iconv > > > + for character set conversions. The relevant functions are p= rovided > > > + by Glibc and so are always available, however they can also= be > > > + provided by the separate GNU libiconv library. If GNU libic= onv is > > > + found when GCC is built (e.g., because its headers are inst= alled > > > + in /usr/local/include) > > > + then the libstdc++.so.6 library will h= ave a > > > + run-time dependency on libiconv.so.2. > > > + If you do not want that run-time dependency then you should= do > > > + one of the following: > > > + > > > + > > > + > > > + > > > + Uninstall the libiconv headers before building GCC. > > > + Glibc already provides iconv so yo= u should > > > + not need libiconv anyway. > > > + > > > + > > > + > > > + > > > + > > > + Download the libiconv sources and extract them int= o the > > > + top level of the GCC source tree, e.g., > > > + > > > + > > > +wget https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.16.tar.gz > > > +tar xf libiconv-1.16.tar.gz > > > +ln -s libiconv-1.16 libiconv > > > + > > > + > > > + This will build libiconv as part of building GCC and li= nk to > > > + it statically, so there is no libiconv.so.2 > > > + dependency. > > > + > > > + > > > + > > > + > > > + Configure GCC with . > > > + This requires the static libiconv.a library, > > > + which is not installed by default. You might need to re= install > > > + libiconv using the con= figure > > > + option to get the static library. > > > + > > > + > > > + > > > + > > > + > > > > > > > > > If GCC 3.1.0 or later on is being used on GNU/Linux, an att= empt > > > diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile= .am > > > index 18f57632c3d..9c3f4aca655 100644 > > > --- a/libstdc++-v3/src/Makefile.am > > > +++ b/libstdc++-v3/src/Makefile.am > > > @@ -278,7 +278,9 @@ CXXLINK =3D \ > > > $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ > > > --mode=3Dlink $(CXX) \ > > > $(VTV_CXXLINKFLAGS) \ > > > - $(OPT_LDFLAGS) $(SECTION_LDFLAGS) $(AM_CXXFLAGS) $(LTLDFLAGS)= -o $@ > > > + $(OPT_LDFLAGS) $(SECTION_LDFLAGS) $(AM_CXXFLAGS) \ > > > + $(LTLDFLAGS) $(LTLIBICONV) \ > > > + -o $@ > > > > > > # Symbol versioning for shared libraries. > > > if ENABLE_SYMVERS > > > > > >