GCC Bugzilla Bug 11074

When building on linux with an external gettext (i.e. using libintl
(libintl_gettext) instead of libc (gettext)), the abi_check program of the
libstdc++-v3 testsuite fails to build, breaking the gcc build.
The problem is that libstdc++ uses gettext, but abi_check is not linked with
libintl.  Simply adding the typical gettext configury to libstdc++-v3 (and
adding @INTLLIBS@ to $(LIBS) for the testsuite Makefile) should make it work (I
manually added -lintl to abi_check_LDADD and this allowed the build to proceed
normally).

Ben,

would you mind looking at this? This seems like a straightforward libstdc++ configury issue. 
Thanks,

Dara

Subject: Re:  libstdc++ fails to build due to gettext
 issue


Sorry I'm working on other bits at the moment. 

-benjamin

Confirmed with gcc 3.3 branch (20030616). Just build gettext with
--with-included-gettext, build 
gcc, and we get undefined symbols. The fix mentioned here appears to solve the
problem.

This doesn't appear to be a bug with gcc-3.4.0 and above. I can configure/build
with 

/mnt/hd/src/gcc/configure --prefix=/mnt/hd/bld/H-x86-gcc
--enable-languages=c,c++ --enable-__cxa_atexit --disable-checking
--with-included-gettext

without a hitch...

*** Bug 15830 has been marked as a duplicate of this bug. ***

*** Bug 15582 has been marked as a duplicate of this bug. ***

Note that the problem persists in gcc 3.4.0.

Specific circumstances:

*1* system has gettext function (in my case, linux, which has gettext in glibc)
*2* system has additional gettext/libintl installation
    (and due to *1* that libintl has a libintl_ symbol prefix)
*3* --with-included-gettext is not specified (no reason to use an old version
    when I have a newer one installed)

Results:

Link error for abi_check: libstdc++.so uses libintl_bindtextdomain and
libintl_bindtextdomain.
These are used from config/locale/gnu/messages_members.h (lines 66 and 88),
so the link errors will only show on systems where the GNU implementation
of the messages facet is chosen.

Currently, HAVE_LIBINTL_H is the only gettext-related autoconf substitution in
libstdc++-v3's configury that I could find; some additional rules will be
needed.

I cannot reproduce this given your carefully plotted steps. Looking back, I see
that some of the related PR's actually specify --disable-nls, which might
actually   be an issue. 

Is that the real problem here?

-benjamin

(In reply to comment #8)
> I cannot reproduce this given your carefully plotted steps. Looking back, I see
> that some of the related PR's actually specify --disable-nls, which might
> actually   be an issue. 
> 
> Is that the real problem here?

No it is not.  The problem seems to be that the configury makes no attempt to
add -lintl to the link step for abi_check.  This in turn comes from the fact
that the standard GNU gettext autoconf macro is not used.
The configury uses GLIBCXX_ENABLE_CLOCALE (line 955 of acinclude.m4) to choose
the clocale implementation.  On linux, the use of glibc is tested and that
causes the GNU implementation to be selected.
Around line 1097, a comment reads
  "don't call AM_GNU_GETTEXT here, assume glibc";
that is the problem for my setup, where libintl.h requires the use of -lintl.
A later test (line 1149) attempts to correct for this, by ensuring that
libintl.h exists (and it does), and that it can find 'gettext' in -lintl
(which it can, because it is simply pulled in from glibc).
The main issue is that included libintl.h for a standalone libintl transforms
calls to gettext() into calls to libintl_gettext() (exactly to avoid pulling
them in from glibc), and AC_SEARCH_LIBS does not add the include, so never
notices it needs -lintl.
My guess is that using AM_GNU_GETTEXT (and a sufficiently recent gettext) would
Do The Right Thing(tm), provided the makefiles would ensure @INTLLIBS@ is added
to $(LIBS) where appropriate.

(In reply to comment #8)> I cannot reproduce this given your carefully plotted
steps. Looking back, I seethat some of the related PR's actually specify
--disable-nls, which mightactually   be an issue. Is that the real problem
here?-benjaminI tried it with --disable-nls and got the same result.

--disable-nls doesn't kill the build, but it does give extra fails in 22_locale
for the messages facet. This is expected.

I'll close this next week unless somebody can tell me what the problem is.

-benjamin

(In reply to comment #11)
> --disable-nls doesn't kill the build, but it does give extra fails in 22_locale
> for the messages facet. This is expected.

Maybe so, but I never used --disable-nls, so whether or not fails are expected
is pretty much irrelevant.

> I'll close this next week unless somebody can tell me what the problem is.

The problem is that the configury assumes that because glibc is present, it can
simply include libintl.h and uses of gettext will Just Work(tm).
However, on my system, gettext is installed separately alongside glibc, which
means that libintl.h defines gettext as a macro that calls the library function
libintl_gettext() (so that the libintl version, and not the glibc version, gets
linked in).
As a result, linking of abi_check fails because libintl_gettext is not found.
I would expect something similar to happen if the included gettext is used, as
that would also add the libintl_ prefix to avoid using the system's gettext().
It's not a _huge_ problem (it's easy enough to manually add -lintl to
abi_check's link line in the makefile) but I would have expected it to be
resolved quite a bit quicker, given the near-trivial fix.

Come to think of it, because using the gnu locale implementation in this case
adds a dependency of libstdc++ on libintl, g++ may need to use -lintl when
linking programs (and if it did, that would also fix the libstdc++ build, as
abi_check would link properly).  So that is probably the better fix.

*** Bug 19468 has been marked as a duplicate of this bug. ***

Not sure if it's a related issue, but attempting to build an AVR cross
G++/libstdc++ complier on OSX presumes --disable-nls, nor using
glibc, fails to build ; although possibly for other reasons as well?

This is still present.
I've now patched acinclude.m4 to detect the library properly (will add as
attachment); it's not ideal but it seems to work.

Also, like I feared, it introduces a dependency on libintl.so when building C++
programs - and g++ does not know to add libintl when linking. As a result,
failures are reported by autoconf tests that check whether the compiler can
produce executables.

Because of the latter, either gcc needs to duplicate some of the libstdc++
configury so that it can add -lintl (and -liconv where applicable) to its g++
link (and this seems a less-than-optimal thing to do), or libstdc++ needs to
improve its i18n checks (ideally using the regular gettext macros, and perhaps
rejecting any solution that requires extra libraries).

Created an attachment (id=8686) [edit]
Patch for libstdc++ acinclude.m4 to detet gettext libraries properly

There hasn't been activity on this for a long time.
Is this still an issue?

I see that my gcc build tree (last used to build 4.3.2 on Sep 26) does not have
any local changes to the libstdc++-v3 directory, according to 'svn diff'. This
at least suggests it is resolved.
A quick check shows that abi_check is now built by dejagnu (abi.exp), not the
Makefile, and that seems to work.

I don't know if the somewhat underlying issue of g++ not automatically linking
with libintl & libiconv is resolved; but libstdc++'s testsuite does seem to run
properly.

Fixed by 4.3.2