For select1st, we noticed that the <functional> header delivered with stdcxx4
did not define select1st, but the aoo delivered <functional> located in
systemstl/tr1 did. Our Makefile flags are set to include the stdcxx4
<functional> instead of the systemstl/tr1 <functional>. To get around this we
modified namedvaluecollection.cxx:
#if defined(__SUNPRO_CC)
#include "../systemstl/tr1/functional"
#esle
#include <functional>
#endif
Let us know if you think there is a better way to address this.
Now we are on to figuring out why comphelper's having a linking error. It is
trying to build libcomphelperC52.so, but it cannot find -lstlport_sunpro.
Raymond
-----Original Message-----
From: Steele, Raymond
Sent: Wednesday, December 11, 2013 8:49 AM
To: 'Herbert Duerr'; [email protected]
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper
Herbert,
The changes [2] worked perfectly for us. Now we are having issues compiling
::std::select1st in namedvaluecollection.cxx on line 175. Apparently,
select1st is not a member of std. It appears that you may have created a ticket
for this one.
https://issues.apache.org/ooo/show_bug.cgi?id=123754
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:[email protected]]
Sent: Tuesday, December 10, 2013 11:25 PM
To: [email protected]
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 11.12.2013 00:16, you wrote:
> Thanks for much of the help you have provided in this venture to help us get
> OpenOffice working in Solaris 11. Because of this we have gotten further into
> the compile of the OpenOffice software. We have moved past the external
> sources compile errors by using a newer version of Boost (1.49) and adding in
> the updates to the emplace_args.hpp file that have been posted on the web.
Speaking of newer boost versions please also see [1] (an enhancement issue I
created to update to boost 1.55). I developed a patch to do that and added it
there to do this. You might want to try it out.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=123817
> However, we are now encountering a problem within the binaryurp in the
> bridge.cxx compile. The first error message is as follows:
>
> "../main/binaryurp/source/cache.hxx", line 113: Error: iterator is not a
> member of
> std::map<com:sun::star::uno::TypeDescription,binaryurp::Cache<com::sun::star::uno::TypeDescription>::Entry>.
>
> Looking at the code, it doesn't seem like an obvious error. The line it
> complains about is inside a struct Entry and the error occurs when defining a
> member variable named prev as a Map::iterator. We could use some insight into
> this problem and would appreciate any help. Thanks.
According to the C++ standard the compiler/STL is right to complain about that
code: the Entry type is incomplete until the declaration is over and a Map
iterator with Entry as its "mapped_type" can not be expected to work while
Entry is being declared.
Some compiler/STL combinations allow it, but some don't. Especially the better
ones (which don't treat all mapped_types the same but have optimized template
specializations) run into problems here.
The good news is that I already developed a replacement for this problematic
code to make it more compatible with standard complying compilers/STLs. Please
try out the patch in [2]. I was about to merge this into trunk soon anyway, but
if you could confirm that it solves the problem on your platform this would
accelerate the integration.
[2] http://svn.apache.org/viewvc?view=revision&revision=1480367
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
