Fantastic! We were actually looking at that [2] yesterday, but were concerned because it was dated 7 months ago. We will implement it and provide feedback.
Thanks again! Raymond -----Original Message----- From: Herbert Duerr [mailto:h...@apache.org] Sent: Tuesday, December 10, 2013 11:25 PM To: dev@openoffice.apache.org 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: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
