[ 
http://issues.apache.org/jira/browse/XALANC-588?page=comments#action_12366198 ] 

Sean Pearce commented on XALANC-588:
------------------------------------

Hi Daivd,

It's been a long time, but I've discovered the following:

> 1. Can you please verify that your application does not make any changes to 
> the default floating point behavior of the application. 
I think our applciations does modify the default behaviour, in that we catch 
FPE signals, and handle them internally - by effectively aborting. Maybe in the 
future we need to be a bit more intelligent, and handle some of these signals a 
bit differently (on Solaris - our product is cross-platform and runs on many 
flavours of Unix and Windows).

We have decided to go with the modified compilation of the library as I stated 
above, because that presently works around our problem(s), and AFAICT we don't 
require XPath comformity (?) as we only do simple XML transformations with XSL.

Also - we're not presently releasing on the AMD64-bit platform due to other 
bugs in the Sun Studio 10 compiler on that platform, but if they've fixed those 
in Sun Studio 11, we may release on that after further testing; It would make 
life easier if the configure script worked out the binary platform, and chose 
the correct -xarch option though :)

Hope you find this information of use.

Regards.

> Floating point exceptions in DoubleSupport::initialize() on Solaris 10 (x86)
> ----------------------------------------------------------------------------
>
>          Key: XALANC-588
>          URL: http://issues.apache.org/jira/browse/XALANC-588
>      Project: XalanC
>         Type: Bug
>   Components: XalanC
>     Versions: 1.10
>  Environment: Sun Solaris 10, Opteron chipset (x86/i386). XercesC++ 2.7  
> XalanC 1.10
> $ CC -V
> CC: Sun C++ 5.7 Patch 117831-02 2005/03/30
> $ cc -V
> cc: Sun C 5.7 Patch 117837-04 2005/05/11
> usage: cc [ options] files.  Use 'cc -flags' for details
>     Reporter: Sean Pearce
>     Assignee: David Bertoni

>
> A couple of issues.
> Prior to compiling, XERCESCROOT and XALANCROOT are configured to point the 
> their respective foliders, and the configurations used as follows:
> Xerces: ./runConfigure -p solaris -c cc -x CC -b 64 -P 
> $P4SRCROOT/Tools/libs/64/SUN/xerces-c_2_7_0
> Xalan:   ./runConfigure -p solaris -c cc -x CC -b 64 -P 
> $P4SRCROOT/Tools/libs/64/SUN/xalanc_1_10
> 1) To compile on this platform, the 'solaris' entries in runConfigure had to 
> be changed to use option '-xarch=amd64' in place of '-xarch=v9' (for XercesC 
> and XalanC)
> 2) After building the libraries, our program was crashing in 
> XalanTransformer::initialize(); (after calling 
> XMLPlatformUtils::Initialize(); of course), with a Floating Point Exception 
> (FPE) in:
> void
> DoubleSupport::initialize()
> {
> #if defined(XALAN_NO_STD_NUMERIC_LIMITS)
>     // We initialize this at here because some
>     // platforms have had issues with signals
>     // if we call sqrt(-2.01) during static
>     // initialization.
> #if defined(XALAN_STRICT_ANSI_HEADERS)
>     s_NaN.d = std::sqrt(-2.01);
> #else
>     s_NaN.d = sqrt(-2.01);
> #endif
> #elif !defined(XALAN_NO_STD_NAMESPACE)
>     // There seems to be problems with various standard libraries, so
>     // this is disabled for now.  We need to revisit this when we
>     // update our autoconf/automake system to detect the right value
>     // for NaN at configuration time.
>     // XALAN_STATIC_ASSERT(std::numeric_limits<double>::has_quiet_NaN);
> #endif
> Removing  #define XALAN_NO_STD_NUMERIC_LIMITS from the 
> Include/SolarisDefinitions.hpp fixes this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to