The error seems alike bug #757385

boost::STATIC_ASSERTION_FAILURE<false> is a compile-time assertion.  It's not supposed to be defined.  It seems BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS is defined on ARM.  But then libs/math/src/tr1/acoshl.cpp makes a call to c_policies::acosh(long double), and the assertion fires.  Either ARM indeed doesn't support long double, and then we need to guard against such uses, or it's a fluke, and we need to fix the BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS detection.

And by fluke, I don't mean fluke, but rather the opposite :)

ARM EABI defines long double as being double on 32-bit ARM. So it should be defined, but it's only guaranteed to be as long as a double. I will look into this a little more, it's odd.

Hmm, that probably means that we are mis-detecting the BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS macro.  The static assertion essentially just checks whether the passed type is something else than long double, because it thinks that long double is not supported on that arch.

That macro is defined in boost/math/tools/config.hpp.  There are several places where this is defined, but the most plausible path is by going through an ifdef on __NO_LONG_DOUBLE_MATH.  That would have to come from glibc.

One additional note, the reason it compiled on 1.46 may be that there we didn't build math at all (it was omitted from the CMake harness by mistake).  Chances are this was broken back then as well.

I got Fedora chroot running on my trimslice and confirmed that the above happens because someone (presumably glibc) defines __NO_LONG_DOUBLE_MATH.

So that seems like a bug.  Another bug likely is that we are trying to build the long-double variants even though they are reportedly not supported.

Hmm, there's unconditional definition of __NO_LONG_DOUBLE_MATH in bits/mathdef.h.  I see that there's a bunch of target-specific mathdef's, but ARM doesn't have it's own, so the generic one is taken, apparently.  From the references that I found on the Internet it seems that in glibc parlance, having "no long double" means that there's no distinct bit width for long double, and therefore ARM is right in defining this.

So the bug is in boost.  I think we might be misrepresenting the meaning of __NO_LONG_DOUBLE here, but I'll have to think about it.

Created attachment 557336 [details]
Build fix

This fixes the obvious problem, i.e. building long double math libraries in face of (apparent) lack of support of long double.  I'll have this propagate to Denis's boost-cmake repo.  I checked that modularized boost project have the same problem, and I'll get in touch with them to have this fixed.

(In reply to comment #8)
> I'll have this propagate to Denis's boost-cmake repo.

Thanks for the patch!

I have integrated it in the CMake-ified Boost repositories (https://github.com/pocb/boost/commit/8aa99f2e318b512e168492b62662a35213fa4f06) and updated the corresponding patch in the Fedora Rawhide Git repository (http://pkgs.fedoraproject.org/gitweb/?p=boost.git;a=blobdiff;f=boost-1.48.0-cmakeify-full.patch;h=eca40d632212af337b2b801f794b0ce06a1ad9e2;hp=c0d4be05ac6f4e840ba09636833fb14a495dbff5;hb=a7311be69805670a2ccf00060439f2129ff7e265;hpb=8cbc559305d8becefa489906a986cd73cc209c7f).

I leave you the honour to launch a Koji build :)

Thanks for the fixes

> I leave you the honour to launch a Koji build :)

Why don't we split it and you do x86 and I'll kick of the ARM one.

(In reply to comment #10)
> Why don't we split it and you do x86 and I'll kick of the ARM one.

Sorry, I meant that Petr would trigger the Koji build.

(In reply to comment #11)
> (In reply to comment #10)
> > Why don't we split it and you do x86 and I'll kick of the ARM one.
> 
> Sorry, I meant that Petr would trigger the Koji build.

haha :-) Sorry, still thanks to you both for you fixes

Created attachment 557346 [details]
Patch for ignoring __NO_LONG_DOUBLE_MATH

The semantics of __NO_LONG_DOUBLE_MATH seem to be that there's no distinct bit width for variables of long double type.  The prototypes of impacted functions (asinhl etc.) are still visible, but they are aliased to their "plain" variant.  The syntax for "long double" was present since the first version of both C and C++ standards, so the prototypes are just always visible, and __NO_LONG_DOUBLE_MATH only determines whether long double has a distinct bit width, i.e. whether a distinct set of _implementations_ is necessary.

On boost side, BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS is somewhat documented in boost/math/tools/config.hpp.  The semantics seem to be that it's defined on targets where compiler or system libraries are buggy or the syntax is missing altogether, but it's apparently also used in the same sense as above ("Dinkumware's std C lib doesn't have true long double precision").

Interestingly, the prototypes are still published, but boost won't generate the corresponding boost_math_*l library with implementations.  From the perspective of a boost client, it all seems fine, until he tries to link.  (At least that's what I think would happen, I don't have full ARM build handy to check.)

Ultimately I don't think upstream is right to omit long double functions like that.  I understand that they would skip this on arches where stuff gets miscompiled or similar.  But ARM implementation is correct, it just happens to have "double" and "long double" of the same length.  It's like suppressing "long long" functions on x86_64. I think __NO_LONG_DOUBLE_MATH should be just ignored.

So this is what's in this patch, together with long-winded rationale.  I'll want to run this by boost upstream.  They might have motives that I don't see.

(In reply to comment #9)
> I have integrated it in the CMake-ified Boost repositories
> (https://github.com/pocb/boost/commit/8aa99f2e318b512e168492b62662a35213fa4f06)
> and updated the corresponding patch in the Fedora Rawhide Git repository

Great, you are quicker than me.  I got all lost in the long double support ;)  Originally I intended to form a pull request on github.

> I leave you the honour to launch a Koji build :)

It's now all in Rawhide.

I'm still spinning the first variant (just the build patch) on ARM, to see what comes out of it, to have something to compare to.

(In reply to comment #10)
> Why don't we split it and you do x86 and I'll kick of the ARM one.

Peter, you may want to just try and grab what's in rawhide and build it.  It might even work :)  Please report back if you do, I'll gladly just download the thing from arm-koji.  I'd also kick start the mainstream rawhide build if it seems to work fine.

Just to clarify, I'm spinning the first variant locally.  I'll then proceed to build the fully patched variant locally, unless you beat me to it, which you as well might, because that won't be until tomorrow morning-ish UTC.

> Peter, you may want to just try and grab what's in rawhide and build it.  It
> might even work :)  Please report back if you do, I'll gladly just download the
> thing from arm-koji.  I'd also kick start the mainstream rawhide build if it
> seems to work fine.

There's now newer build in mainline koji than the one from the 16th

Created attachment 557454 [details]
Additional build fix

The previous build fix doesn't do the right thing because it sucks in the system-installed boost header instead of the one in the build tree.  I ended up having to create a dedicated project for the long double support detection, and try_compile that.  I'm spinning another local build now.

Denis, this patch should also go to your cmake-boost upstream.

Ok, it seems that the ARM builds of long double functions are sane.  I made a manual run of test_tr1.cpp (on ARM), and it passes.  I'll apply another patch for a boost-polygon bug and start a build in mainline Fedora.

I built boost with these patches in rawhide.  I'm going to close this now.  If boost still fails on ARM, or if you get a "long double not supported" message during configuration, please re-open.

Upstream submission:
https://svn.boost.org/trac/boost/ticket/6459