This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patches] C++ linking problem when locale are disabled in eglic.


On Tue, Mar 13, 2012 at 6:43 AM, Jonathan Wakely <jwakely.gcc@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]