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++ > <libstd...@gcc.gnu.org> wrote: > > > > Pushed to trunk now. > > > > On Wed, 13 Apr 2022 at 15:24, Jonathan Wakely via Libstdc++ > > <libstd...@gcc.gnu.org> 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=static, 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⢠for users who (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 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=static 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 @@ > > > <varlistentry> > > > <term>linux</term> > > > > > > + <listitem> > > > + <para> > > > + The 'gnu' locale model makes use of <function>iconv</function> > > > + for character set conversions. The relevant functions are > > > provided > > > + 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 installed > > > + in <filename class="directory">/usr/local/include</filename>) > > > + then the <filename>libstdc++.so.6</filename> library will have a > > > + run-time dependency on <filename>libiconv.so.2</filename>. > > > + If you do not want that run-time dependency then you should do > > > + one of the following: > > > + </para> > > > + <itemizedlist> > > > + <listitem> > > > + <para> > > > + Uninstall the libiconv headers before building GCC. > > > + Glibc already provides <function>iconv</function> so you > > > should > > > + not need libiconv anyway. > > > + </para> > > > + </listitem> > > > + <listitem> > > > + <para> > > > + <link > > > linkend="https://www.gnu.org/software/libiconv/#downloading";> > > > + Download</link> the libiconv sources and extract them into the > > > + top level of the GCC source tree, e.g., > > > + </para> > > > +<programlisting> > > > +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 > > > +</programlisting> > > > + <para> > > > + This will build libiconv as part of building GCC and link to > > > + it statically, so there is no > > > <filename>libiconv.so.2</filename> > > > + dependency. > > > + </para> > > > + </listitem> > > > + <listitem> > > > + <para> > > > + Configure GCC with > > > <option>--with-libiconv-type=static</option>. > > > + This requires the static <filename>libiconv.a</filename> > > > library, > > > + which is not installed by default. You might need to > > > reinstall > > > + libiconv using the <option>--enable-static</option> > > > configure > > > + option to get the static library. > > > + </para> > > > + </listitem> > > > + </itemizedlist> > > > + </listitem> > > > + > > > <listitem> > > > <para> > > > 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 = \ > > > $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ > > > --mode=link $(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 > > > > > >
