This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: [Patch] Fix libstdc++ build when using uclibc instead of glibc


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
>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.

If uclibc does define that function then we should figure out why
libstdc++ fails to see it, and see if we can fix that, so that
std::isfinite() gets declared and the existing code in <random> starts
working.

i.e. I'd like to be sure there isn't some deeper underlying problem
that should be addressed, rather than just working around it.


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