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 attachment 8686 [details] Patch for libstdc++ acinclude.m4 to detect 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