xalan-c-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Elzen <Martin.El...@usoft.com>
Subject RE: Building xalan-c 1.11 with Solaris 10 and gcc 3.2.3
Date Wed, 28 Nov 2012 10:35:25 GMT
Robert,

The error of something being implicitly friends with itself is not something I'm familiar
with, so I guess that's going to have to be left to google.  The one other thing I had to
do which I haven't mentioned yet to get things building with solaris studio 12.3 is:

Change src/xalanc/Include/SolarisDefinitions.hpp as follows:
remove the #if/#else/#endif around the XALAN_HAS_STD_ITERATORS/XALAN_HAS_STD_DISTANCE lines.
You might also have to do some similar "mucking about" with such a file.  If you do, you'll
probably need to do a make clean before restarting the build...

Sincerely,
Martin

From: robert.hillier@oracle.com [mailto:robert.hillier@oracle.com]
Sent: Wednesday, November 28, 2012 11:17 AM
To: c-users@xalan.apache.org
Subject: Re: Building xalan-c 1.11 with Solaris 10 and gcc 3.2.3

Martin,

Putting the #if defined(SOLARIS) around the isnan function seems to sort the problem.  (Though
using __GCC__ doesn't).

With the isnan problem fixed, I seem to run into a new problem.  I'm now getting the following
error:

In file included from <myPath>/xalan-c-1.11/c/src/xalanc/DOMSupport/XalanNamespacesStack.cpp:20:
<myPath>/xalan-c-1.11/c/src/xalanc/Include/XalanDeque.hpp: In instantiation of `xalanc_1_11::XalanDequeIterator<xalanc_1_11::XalanDequeConstIteratorTraits<xalanc_1_11::XalanNamespace>,
xalanc_1_11::XalanDeque<xalanc_1_11::XalanNamespace, xalanc_1_11::MemoryManagedConstructionTraits<xalanc_1_11::XalanNamespace>
> >':
<myPath>/xalan-c-1.11/c/src/xalanc/DOMSupport/XalanNamespacesStack.hpp:151:   instantiated
from here
<myPath>/xalan-c-1.11/c/src/xalanc/Include/XalanDeque.hpp:72: class
   `
   xalanc_1_11::XalanDequeIterator<xalanc_1_11::XalanDequeConstIteratorTraits<xalanc_1_11::XalanNamespace>,
   xalanc_1_11::XalanDeque<xalanc_1_11::XalanNamespace,
   xalanc_1_11::MemoryManagedConstructionTraits<xalanc_1_11::XalanNamespace> >
   >' is implicitly friends with itself
<myPath>/xalan-c-1.11/c/src/xalanc/Include/XalanDeque.hpp: In instantiation of `xalanc_1_11::XalanDequeIterator<xalanc_1_11::XalanDequeConstIteratorTraits<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry>,
xalanc_1_11::XalanDeque<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry, xalanc_1_11::ConstructWithMemoryManagerTraits<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry>
> >':
<myPath>/xalan-c-1.11/c/src/xalanc/DOMSupport/XalanNamespacesStack.hpp:301:   instantiated
from here
<myPath>/xalan-c-1.11/c/src/xalanc/Include/XalanDeque.hpp:72: class
   `
   xalanc_1_11::XalanDequeIterator<xalanc_1_11::XalanDequeConstIteratorTraits<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry>,

   xalanc_1_11::XalanDeque<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry,

   xalanc_1_11::ConstructWithMemoryManagerTraits<xalanc_1_11::XalanNamespacesStack::XalanNamespacesStackEntry>
   > >' is implicitly friends with itself

Did you come across this as well, by any chance?

Thanks,

Rob


On 28/11/12 10:01, Martin Elzen wrote:
Hi Robert,

Your problem does seem familiar.  I ran across an issue like that with the Solaris compiler
which seems to be kind of like the MS compiler in the respect that even when you use a C++
include file like <cmath>, which instead of to 'inserting' functions into the std namespace,
simply inserts them into the global namespace, and then "doesn't know" about the same functions
when std:: is prepended to their call.... The following fixed my issue:


Change src/xalanc/PlatformSupport/DoubleSupport.hpp as follows:
- add an #if defined(SOLARIS) / #include <math.h> / #endif section
- in the isNAN(double) function put an #if defined(SOLARIS) / return isnan(theNumber) != 0;
/ #else / and #endif around the return std::isnan(theNumber) != 0; line
To change it for GNU g++ you'd need to replace the two occurrences of SOLARIS in the above
with __GCC__ if memory serves.  When you do that, is your compilation issue gone?

Sincerely,
Martin

From: Robert Hillier [mailto:robert.hillier@oracle.com]
Sent: Tuesday, November 27, 2012 6:13 PM
To: c-users@xalan.apache.org<mailto:c-users@xalan.apache.org>
Subject: Building xalan-c 1.11 with Solaris 10 and gcc 3.2.3

Hello,

I'm having some problems building the latest xalan-c on a Solaris 10 platform.

I configure with the following options:

./runConfigure -p solaris -c gcc -x g++ -P /my/dest

When I try and build, I get the following error when compiling DOMStringHelper.cpp:


In file included from

<myPath>/xalan-c-1.11/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp:50:

<myPath>/xalan-c-1.11/c/src/xalanc/PlatformSupport/DoubleSupport.hpp:

In

    static member function `static bool

    xalanc_1_11::DoubleSupport::isNaN(double)':

<myPath>/xalan-c-1.11/c/src/xalanc/PlatformSupport/DoubleSupport.hpp:86:

`

    isnan' undeclared in namespace `std'

gmake[2]: *** [../../obj/DOMStringHelper.o] Error 1


Has anyone come across this before?

Thanks,

Rob

________________________________
The information contained in this communication is intended solely for the use of the individual
or entity to whom it is addressed and others authorized to receive it. It may contain confidential
or legally privileged information. If you are not the intended recipient you are hereby notified
that any disclosure, copying, distribution or taking any action in reliance on the contents
of this information is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify us immediately by forwarding this email to MailAdmin@usoft.com<mailto:MailAdmin@usoft.com>
and then delete it from your system.

USoft is neither liable for the proper and complete transmission of the information contained
in this communication nor for any delay in its receipt.

Mime
View raw message