This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Fix libstdc++ build when using uclibc instead of glibc
- From: Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>,libstdc++ at gcc dot gnu dot org
- Cc: Steve Ellcey <sellcey at imgtec dot com>,gcc-patches at gcc dot gnu dot org
- Date: Thu, 07 Jan 2016 20:56:09 +0100
- Subject: Re: [Patch] Fix libstdc++ build when using uclibc instead of glibc
- Authentication-results: sourceware.org; auth=none
- References: <6ecc7322-9335-4197-9508-34af9946c491 at BAMAIL02 dot ba dot imgtec dot org> <20160106203447 dot GB8785 at redhat dot com> <1452113128 dot 29343 dot 11 dot camel at ubuntu-sellcey> <20160106230244 dot GD8785 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1601070723450 dot 1819 at laptop-mg dot saclay dot inria dot fr> <20160107112349 dot GA30323 at redhat dot com>
On January 7, 2016 12:23:49 PM GMT+01:00, Jonathan Wakely <jwakely@redhat.com> wrote:
>On 07/01/16 07:28 +0100, Marc Glisse wrote:
>>On Wed, 6 Jan 2016, Jonathan Wakely wrote:
>>
>>>On 06/01/16 12:45 -0800, Steve Ellcey wrote:
>>>>On Wed, 2016-01-06 at 20:34 +0000, Jonathan Wakely wrote:
>>>>>On 05/01/16 14:43 -0800, Steve Ellcey wrote:
>>>>>>While trying to build GCC with uclibc instead of glibc I ran into
>a build
>>>>>>failure in libstdc++. uclibc doesn't seem to provide the
>>>>>isfinite function
uClibc provides an infinite macro. Make sure to enable C99 math though.
OK?
TIA,
>>>>>>like glibc does so that means that libstdc++ doesn't have
>std::isfinite.
>>>>>>
>>>>>>This in turn caused include/ext/random.tcc to not compile because
>it uses
>>>>>>std::isfinite. I can easily see how this might be considered a
>uclibc
>>>>>>bug but given that it is the only build problem I ran into I was
>hoping
>>>>>>we could fix it in libstdc++ by using __builtin_finite instead of
>>>>>
>>>>>Shouldn't that be __builtin_isfinite not __builtin_finite ?
>>>>
>>>>You are right. For some reason I thought that isfinite was
>implemented
>>>>as __builtin_finite and that there was no __builtin_isfinite. I am
>not
>>>>sure why I thought that but it does not seem to be the case. I will
>>>>update my patch, retest, and resubmit.
>>>
>>>Thanks.
>>>
>>>Regarding the substance of the patch, the usual approach would be to
>>>gate the relevant parts of <random> (or even the whole thing) on the
>>>presence of std::isinfinite, but that would presumably disable the
>>><random> functionality completely for uclibc. If using the builtin
>>>works reliably then I'm OK with that.
>>>
>>>However, I would expect that for un-optimized code the builtin will
>>>just emit a call to isfinite() in the C library, and so if uclibc
>>>doesn't define that at all then that will result in a linker error.
>>
>>I thought that was half the reason you asked for isfinite (the other
>>half being that __builtin_isfinite is generic while __builtin_finite
>>(and the [fl] variants) is not). If you look at builtins.def, isfinite
>
>>is declared with DEF_GCC_BUILTIN (no library fallback), as opposed to
>>finite with DEF_EXT_LIB_BUILTIN.
>
>You give me too much credit :-)
>
>I was only concerned with the generic property, but if it doesn't
>require a library fallback then __builtin_isfinite should work fine,
>and we don't need to worry about investigating whether something is
>wrong with the autoconf checks.