On Tue, Mar 13, 2012 at 6:43 AM, Jonathan Wakely <jwakely....@gmail.com> wrote: >> 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.
As a glibc maintainer I agree with Jonathan's general statements. We need the help of the developer community to test the various configurations and patches are always welcome. Cheers, Carlos.
