This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: C++ linking problem when locale are disabled in eglic.
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: paul dot chavent at fnac dot net
- Cc: gcc at gcc dot gnu dot org, patches at eglibc dot org, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 13 Mar 2012 09:37:05 +0000
- Subject: Re: C++ linking problem when locale are disabled in eglic.
- References: <1314119.16631331624515507.JavaMail.www@wsfrf1110>
On 13 March 2012 07:41, <paul.chavent@fnac.net> wrote:
> Hello.
This should have been CC'd to the libstdc++ list too.
> C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with OPTION_EGLIBC_LOCALE_CODE=n.
>
> It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs in early glibc-2.2.x series anymore. So, it doesn't detect the lack of newlocale, duplocale, freelocale, nl_langinfo_l and uselocale. On the other hand, there is a new test for the presence of uclibc (!defined(__UCLIBC__)).
>
> I solved the problem with the '--enable-clocale=generic' option when configuring gcc.
>
> So my question to the gcc team is : "should gcc detect the lack of these functions with eglibc" , or using --enable-clocale=generic is the good practice ?
Ideally, yes. IIRC we require a minimum version of glibc and assume
that a sufficiently new glibc will always provide those functions.
That assumption predates eglibc and the optional modules. Patches to
improve libstdc++'s configure are welcome.