You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pedro Giffuni <pf...@apache.org> on 2013/01/04 06:19:51 UTC
Yes, the Windows build is broken due to boost
Hi;
As title says the windows build got broken by my attempt to use boost::math in Calc. The linux buildbots are fine so it seems some interaction between MSVC and boost.
hdu@ kindly provided a log:
https://issues.apache.org/ooo/attachment.cgi?id=80094&action=edit
I am completely clueless and some expert help is welcome. I guess I will never get used to this: it is sad that the code was actually working great on UNIX but the Windows port is important so I will revert tomorrow (unless someone gets ahead of me).
Pedro.
Re: Yes, the Windows build is broken due to boost
Posted by Pedro Giffuni <pf...@apache.org>.
----- Messaggio originale -----
> Da: Herbert Duerr <hd...@apache.org>
...
>
> Hi,
>
> On 04.01.2013 06:19, Pedro Giffuni wrote:
>> As title says the windows build got broken by my attempt to use boost::math
> in Calc. The linux buildbots are fine so it seems some interaction between MSVC
> and boost.
>>
>> hdu@ kindly provided a log:
>> https://issues.apache.org/ooo/attachment.cgi?id=80094&action=edit
>>
>> I am completely clueless and some expert help is welcome. I guess I will
> never get used to this: it is sad that the code was actually working great on
> UNIX but the Windows port is important so I will revert tomorrow (unless someone
> gets ahead of me).
>
> I think I found the reason and an explanation of what has gone wrong:
> - the stl/complex.h header gets included somehow
> - it defines a function abs(complex<T>)
> - on windows abs() usually comes from math.h
> - so stlport<=4 on windows doesn't declare stl::abs(double) and the like
> => there is a problem if stl::abs(double) is needed
> - the atanh(double) which depends on stl::abs() is thus considered a failure
> from C++'s SFINAE (Substitution Failure is not an Error) perspective and
> thus the needed template is not propagated to
>
> In short: adding a
> #define _STLP_HAS_NATIVE_FLOAT_ABS
> before the #include<boost/math/special_functions/*> lines in interpr1.cxx
> and interpr3.cxx solves the problem, but it is of course too unclean, it just
> proves the point. To get things going again adding the define conditionally on
> the WNT target isn't too unreasonable.
>
> Interestingly stlport 5.2 adds the define itself unconditionally also for
> Windows.
>
> So in summary the problem was caused by our code base having quite an old
> stlport interacting with a quite new boost library and the resulting trouble
> being hidden by the SFINAE mechanism. Yay! Experiences like this or like issue
> 72248 are interesting reality checks, especially when discussing fancy template
> libraries with their enthusiasts.
>
Nice find! Thank you Herbert, these type of issues are extremely difficult to hunt
without the platform in question!
And I guess we have another reason to kill stlport!
Pedro.
> Herbert
>
Re: Yes, the Windows build is broken due to boost
Posted by Herbert Duerr <hd...@apache.org>.
Hi,
On 04.01.2013 06:19, Pedro Giffuni wrote:
> As title says the windows build got broken by my attempt to use boost::math in Calc. The linux buildbots are fine so it seems some interaction between MSVC and boost.
>
> hdu@ kindly provided a log:
> https://issues.apache.org/ooo/attachment.cgi?id=80094&action=edit
>
> I am completely clueless and some expert help is welcome. I guess I will never get used to this: it is sad that the code was actually working great on UNIX but the Windows port is important so I will revert tomorrow (unless someone gets ahead of me).
I think I found the reason and an explanation of what has gone wrong:
- the stl/complex.h header gets included somehow
- it defines a function abs(complex<T>)
- on windows abs() usually comes from math.h
- so stlport<=4 on windows doesn't declare stl::abs(double) and the like
=> there is a problem if stl::abs(double) is needed
- the atanh(double) which depends on stl::abs() is thus considered a
failure from C++'s SFINAE (Substitution Failure is not an Error)
perspective and thus the needed template is not propagated to
In short: adding a
#define _STLP_HAS_NATIVE_FLOAT_ABS
before the #include<boost/math/special_functions/*> lines in
interpr1.cxx and interpr3.cxx solves the problem, but it is of course
too unclean, it just proves the point. To get things going again adding
the define conditionally on the WNT target isn't too unreasonable.
Interestingly stlport 5.2 adds the define itself unconditionally also
for Windows.
So in summary the problem was caused by our code base having quite an
old stlport interacting with a quite new boost library and the resulting
trouble being hidden by the SFINAE mechanism. Yay! Experiences like this
or like issue 72248 are interesting reality checks, especially when
discussing fancy template libraries with their enthusiasts.
Herbert