headers
Steve M. Robbins | 12 Nov 03:01
Favicon

BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS causes build to fail

Hi,

This is an expanded question from a post I made yesterday to the main
boost list.  I think boost-build might be a better audience.

My immediate issue is that Boost 1.36 and later end with (an expected)
build failure on certain architectures -- those that define
BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS.  This causes the builds to
be rejected by the Debian build daemon machines [1] as follows:

  libs/math/build/has_long_double_support.cpp:9:2: error: #error "long double support is not
supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built."
  ...failed gcc.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/gcc-4.3.2/release/debug-symbols-on/link-static/has_long_double_support.o...

and several others, ending with:

  ...failed updating 8 targets...
  ...skipped 368 targets...
  ...updated 2074 targets...
  make: *** [build-stamp] Error 1

I don't really know how to solve this and would appreciate any guidance navigating
Boost.Build.  I'm perfectly willing to create and support a Debian-only patch
for this.

I know that there are other things in my build logs that look like
"expected" failures and are NOT fatal; e.g.

  libs/config/test/all/../no_std_locale_fail.cpp:27:2: error: #error "this file should not compile"
  libs/config/test/all/../no_std_locale_fail.cpp: In function 'int main(int, char**)':
(Continue reading)

Permalink | Reply |
headers
Steve M. Robbins | 12 Nov 04:42
Favicon

Re: BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS causes build to fail

On Tue, Nov 11, 2008 at 08:04:07PM -0600, Steve M. Robbins wrote:

> Alternatively, since the test is used to suppress the long double
> version of the TR1 library, could I patch the build system to avoid
> building it when a certain parameter is given on the bjam command
> line?  I can easily arrange for the parameter to be present on the
> affected architectures.

OK, after a bit of poking around, I came up with the following hack.
I'm interested in ideas for improvement.  Could something like this
make it into Boost itself (minus the ECHOS, of course)?

--- boost1.36-1.36.0.orig/libs/math/build/Jamfile.v2
+++ boost1.36-1.36.0/libs/math/build/Jamfile.v2
@@ -51,7 +51,18 @@
 sph_neumann
 ;

-compile has_long_double_support.cpp ;
+if --disable-long-double in [ modules.peek : ARGV ]
+{
+    build-long-double = false ;
+}
+else
+{
+    build-long-double = true ;
+    compile has_long_double_support.cpp ;
+}
+
+ECHO "Build long double: " $(build-long-double) ;
(Continue reading)

Permalink | Reply |
headers
Steven Watanabe | 12 Nov 05:49

Re: BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS causes build to fail

AMDG

Steve M. Robbins wrote:
>> Alternatively, since the test is used to suppress the long double
>> version of the TR1 library, could I patch the build system to avoid
>> building it when a certain parameter is given on the bjam command
>> line?  I can easily arrange for the parameter to be present on the
>> affected architectures.
>>     
>
> OK, after a bit of poking around, I came up with the following hack.
> I'm interested in ideas for improvement.  Could something like this
> make it into Boost itself (minus the ECHOS, of course)?
>
>
> <snip>
>   

Maybe this should be split up in Jamroot so that we can use:
--without-math_tr1l --without-math_c99l?

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Permalink | Reply |
headers
Steve M. Robbins | 15 Nov 17:47
Favicon

Re: BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS causes build to fail

On Tue, Nov 11, 2008 at 08:49:44PM -0800, Steven Watanabe wrote:
> AMDG
>
> Steve M. Robbins wrote:
>>> Alternatively, since the test is used to suppress the long double
>>> version of the TR1 library, could I patch the build system to avoid
>>> building it when a certain parameter is given on the bjam command
>>> line?  I can easily arrange for the parameter to be present on the
>>> affected architectures.
>>>     
>>
>> OK, after a bit of poking around, I came up with the following hack.
>> I'm interested in ideas for improvement.  Could something like this
>> make it into Boost itself (minus the ECHOS, of course)?

The initial hack is not sufficient.  Below is the patch I ended up
using, for the record.

> Maybe this should be split up in Jamroot so that we can use:
> --without-math_tr1l --without-math_c99l?

Maybe.  My case is that some architectures in Debian support long
double math and some don't.  So I want either both built or neither
built.  

What use case do you envision for separate options?

Cheers,
-Steve
(Continue reading)

Permalink | Reply |

Gmane