On 13 March 2012 09:37, Jonathan Wakely wrote: > On 13 March 2012 07:41, <paul.chav...@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.
That wasn't very clear, sorry. I meant that ideally libstdc++ would detect the lack of the functions. In the absence of that detection --enable-clocale=generic is a reasonable workaround. > 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.
