openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steele, Raymond" <raymond.ste...@lmco.com>
Subject RE: EXTERNAL: Re: Building comphelper
Date Thu, 09 Jan 2014 21:48:56 GMT
Herbert, 

Attached is a copy of the stack trace when we tried to launch both the Word Processor and
the Spreadsheet application in OpenOffice.  We are going to attempt to resolve the crash based
on this information, but if anything pops out at you, please let us know.

Thanks,

David Meffe

-----Original Message-----
From: Steele, Raymond 
Sent: Thursday, January 09, 2014 8:47 AM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

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:hdu@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


Mime
View raw message