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 B1A04385735E for ; Wed, 20 Apr 2022 12:56:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B1A04385735E Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-27-B-RIm1DfMgqtvSYTL7JNZQ-1; Wed, 20 Apr 2022 08:56:28 -0400 X-MC-Unique: B-RIm1DfMgqtvSYTL7JNZQ-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-2f182a726abso14785107b3.1 for ; Wed, 20 Apr 2022 05:56:28 -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=tSPR4eGNrtuFApEN3+BwhGNJrctBl/bkBWUbx9pmyrc=; b=VAV8E8EahGY7upVkl8P4XMr9Nuk07tC26DjyH5HvhU+dC12XjCY4I8ZdL+kk2jRtz9 T3+dqCEJ/vhD0l5tgTIhlURtLWqgjjcy5/S2gkULsK2d6lgPMDwLl4MhgZwJAY4hdWl5 nuQdhiR22EQ+rp80nduz1Jya0wbxNKK2Z7s/DT4IOCF3STp1zKuja421jfekby1JQ8Z1 YflSS+zsF76gahQuai+TV63HO0e/zg/0t+dIjuXoCu2mkgeaT+ms6KG8xL8E4fzK6vz/ f6mAWD9MrfpqLbsKdsQHyUCJxbPG+ZtTZSUSpH6mvsARrvWigj3erDyUca+tEdD5AB6l gfZw== X-Gm-Message-State: AOAM531MmVwRwLvv8AvFMNUZ5ghbOa4+dd0ftCnxLZq2qwllO8GDvDwA wMkMgFJ5B4Q/5IpB/aQxf+mN5gLvOA30Wlu1zrP1ecAeSBEMcodnqZBYe1P4AcT49E5H1ykCeuW AzeMd188ry6PaNGMyNT0naaCxuIZ04ak= X-Received: by 2002:a05:6902:509:b0:641:3b3c:9ca0 with SMTP id x9-20020a056902050900b006413b3c9ca0mr19418364ybs.415.1650459387933; Wed, 20 Apr 2022 05:56:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQIrj+TNIhxLcpXyw9O26Ie2r4lRil1Jn3QfZudXSXpUBHvLGO6KURAOP5XLOkk67RYfsVMf2wTzDZdaTQAnA= X-Received: by 2002:a05:6902:509:b0:641:3b3c:9ca0 with SMTP id x9-20020a056902050900b006413b3c9ca0mr19418342ybs.415.1650459387659; Wed, 20 Apr 2022 05:56:27 -0700 (PDT) MIME-Version: 1.0 References: <20220413142359.577396-1-jwakely@redhat.com> In-Reply-To: <20220413142359.577396-1-jwakely@redhat.com> From: Jonathan Wakely Date: Wed, 20 Apr 2022 13:56:16 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602] To: Jonathan Wakely 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=-14.6 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_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: Wed, 20 Apr 2022 12:56:31 -0000 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 installed, > 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 rpath > solution. The proposed patch makes it Just Work=E2=84=A2 for users who (f= or > 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 system > 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 provi= ded > + by Glibc and so are always available, however they can also be > + provided by the separate GNU libiconv library. If GNU libiconv = is > + found when GCC is built (e.g., because its headers are installe= d > + in /usr/local/include) > + then the libstdc++.so.6 library will have = 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 you sh= ould > + not need libiconv anyway. > + > + > + > + > + > + Download the libiconv sources and extract them into th= e > + 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 link t= o > + it statically, so there is no libiconv.so.2 > + dependency. > + > + > + > + > + Configure GCC with configu= re > + option to get the static library. > + > + > + > + > + > > > If GCC 3.1.0 or later on is being used on GNU/Linux, an attempt > 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 >