Just to give you an update. We were able compile debugbase.cxx by including /opt/solarisstudios12.3/prod/include/CC/stlport4, but the next module wanted ../include/CC/Cstd. Then it went back and forth. There seems to be a disconnect between which C/C++ implementation it wants and I do not think they are compatible with each other. As of now, we've loaded the Apache C++ stdcxx4 implementation so that we can retry using just the one implementation. However, we've noticed that stdcxx4 does not provide hash_map and hash_set, among others, so we included ../main/stlport/system1/ files. Hopefully, this will work for us. If you have any comments ideas, please let us know.
Raymond -----Original Message----- From: Steele, Raymond Sent: Tuesday, December 03, 2013 9:22 AM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Herbert, Thanks for the information. Sorry about the PDF. Unfortunately, we are unable to do a simple copy and paste because of the way are system is setup. The only other option that I have is to type the output, but that would have taken much longer. We just implemented the patch, but are still receiving the same output. We are investigating now. Thanks, Raymond -----Original Message----- From: Herbert Duerr [mailto:h...@apache.org] Sent: Tuesday, December 03, 2013 3:36 AM To: dev@openoffice.apache.org Cc: Meffe, David K; Steele, Raymond Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, On 02.12.2013 23:34, Steele, Raymond wrote: > Let me know if you did not get the attachment. Attachments usually get stripped on the mailing list, but I got it because was on CC. As the PDF only contained scanned text a simple copy+paste of that text would have been better. > We are having trouble interpreting the boost preprocessor macros. We are > receiving the following output when compiling sal/osl/all. I've attached the > output as a pdf. Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted map::value_type and const correctness. Please try this patch to make the construct more digestible: --- main/sal/osl/all/debugbase.cxx +++ main/sal/osl/all/debugbase.cxx @@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject( { if (rData.m_bStoreAddresses) { osl::MutexGuard const guard( osl_detail_ObjectRegistry_getMutex() ); - std::pair<osl::detail::VoidPointerSet::iterator, bool> const insertion( - rData.m_addresses.insert(pObj) ); - DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" ); - static_cast<void>(insertion); + const bool bOK = rData.m_addresses.insert(pObj).second; + DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" ); + (void)bOK; // unused for non-debug } else { osl_incrementInterlockedCount(&rData.m_nCount); Please report whether this helps, I'll commit the change then. Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
