Herbert, We found a work around for this problem, but believe it may be implemented incorrectly.
We added the following to the top of fmtatr2.cxx: #ifndef _RWSTD_NO_MEMBER_TEMPLATES #define _RWSTD_NO_MEMBER_TEMPLATES 1 #endif The compile of sw then began compiling correctly. Any thoughts? Raymond -----Original Message----- From: Steele, Raymond Sent: Wednesday, January 08, 2014 5:03 PM To: 'Herbert Duerr'; dev@openoffice.apache.org Cc: Meffe, David K Subject: RE: EXTERNAL: Re: Building comphelper Hey Herbert, Thanks for the quick response and your fix worked. The svx module built perfectly. I don't know why we are having these errors appear now that we are recompiling in debug mode. Unfortunately we ran into another problem at the end of the day here (and after nearly a whole day of compiling and everything looking good) and we'd thought we'd send off a quick message to you to see if you might have an answer. While rebuilding the "sw" module, the build of the "fmtatr2" file failed. The first error message in the failure references the /usr/include/stdcxx4/rw/_autoptr.h file saying that the file "Could not find a match for std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>::auto_ptr_ref<std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>::_TypeU>(std::auto_ptr<conststd::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>, const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> *) needed in std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> > ::operator std::auto_ptr_ref<const std::auto_ptr_ref<const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange>><const std::deque<com::sun::star::uno::Reference<com::sun::star::text::XTextRange> >>() " Raymond and I know that this reference is located in the memory.h file, but it doesn't appear that any of the files in the /main/sw/source/core/txtnode include the memory.h file even though it may be included in one of the other included files. Is it possible that something inside the OpenOffice files might be conflicting with the definition or usage of the auto_ptr_ref defined in the /usr/include/stdcxx4/memory.h? do we need to include memory.h inside any of the files inside /main/sw/source/core/txtnode? Is there a header definition that we need to change similar to the erf problems that we encountered previously? Thanks, David Meffe -----Original Message----- From: Herbert Duerr [mailto:h...@apache.org] Sent: Wednesday, January 08, 2014 4:06 AM To: dev@openoffice.apache.org Cc: Steele, Raymond; Meffe, David K Subject: Re: EXTERNAL: Re: Building comphelper Hi Raymond, Hi David, On 07.01.2014 23:11, Steele, Raymond wrote: > Raymond and I remain stuck on the last issue that we wrote to you about. We > would like to better encapsulate our problem and see if you might be able to > provide more clarification on what we might be able to try. > > 1. We have performed a directory clean and restarted the build --all > process from the beginning with the debug flag set. This time we are not > using the multi-processing commands. > 2. The build process proceeds without error, even compiling all the files > up to the svx module. > 3. When the svx module is finished compiling and the LNK of the > Library/libsvxcore.so is being performed the process stops with an "Undefined > symbol" linking error. > 4. The symbol is ParagraphData&ParagraphData::operator(const > ParagraphData&) and it used to complain about this file in the e3dundo.o. Wasn't it complaining about a missing ParagraphDataVector symbol originally? > 5. Since the ParagraphData didn't appear in e3dundo neither did the > OutlinerParaObject, I was at a loss for this linking error, but there was an > #include <editeng/outlobj.hxx>. Since that is the location of > OutlinerParaObject, I have commented out that include to see what would > happen. The result is the system still compiled, but the linking failed > again, this time in another location. > 6. The new location that we got the same "Undefined symbol" error link > message on was in the file sdrlinefillshadowtextattribute.o located in the > attribute directory. This time I was unable to find a #include > <editeng/outlobj.hxx> in either the header or source file. However > sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which > includes sdrtextattribute. > 7. sdrtextattribute was the first location we have found where the > OutlinerParaObject is used and the #include <editeng/outlobj.hxx>. Since we > had not found this object before (at least in the path that was failing), > this was the first thing that made some sense in this problem. > 8. We have reviewed your last email, but are having a difficult time > understanding what you recommended. It appeared you were recommending we > modify the OutlinerParaObject constructor, but how? You wanted us to remove > the ParagraphDataVector parameter? Or did you want us to create a different > constructor? What would the constructor look like? I was suggesting to add another constructor that didn't have the problem of needing a ParagraphDataVector symbol. Does this patch work for you? Since this makes svx "binary incompatible" with its original you need to do a "build --prepare --from svx" when you apply it. --- main/editeng/inc/editeng/outlobj.hxx +++ main/editeng/inc/editeng/outlobj.hxx @@ -46,10 +46,8 @@ private: public: // constructors/destructor - OutlinerParaObject( - const EditTextObject& rEditTextObject, - const ParagraphDataVector& rParagraphDataVector = ParagraphDataVector(), - bool bIsEditDoc = true); + OutlinerParaObject( const EditTextObject&, const ParagraphDataVector&, bool bIsEditDoc = true); + OutlinerParaObject( const EditTextObject&); OutlinerParaObject(const OutlinerParaObject& rCandidate); ~OutlinerParaObject(); --- main/editeng/source/outliner/outlobj.cxx +++ main/editeng/source/outliner/outlobj.cxx @@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject& rEditTextObject, co { } +OutlinerParaObject::OutlinerParaObject( const EditTextObject&) +: mpImplOutlinerParaObject( new ImplOutlinerParaObject( rEditTextObject.Clone(), ParagraphDataVector(), true)) +{} + OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject& rCandidate) : mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject) { > 9. Also even after all of this, do you think that if we modify the > OutlinerParaObject that the rest of the svx will link correctly and that all > these errors we have seen from this problem resulted from an error in the > OutlinerParaObject and our compiler? I sure hope so ;-) > Once again, thanks for all your help in advance. You're welcome! > I hope you had a good holiday season. We look forward to hearing back from > you. BTW: I'll also be away next week. Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
