You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Steele, Raymond" <ra...@lmco.com> on 2014/01/07 23:11:34 UTC
RE: EXTERNAL: Re: Building comphelper
Herbert,
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.
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?
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?
Once again, thanks for all your help in advance. I hope you had a good holiday season. We look forward to hearing back from you.
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, December 20, 2013 6:41 AM
To: Steele, Raymond; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
Hi Raymond,
On 20.12.2013 00:12, Steele, Raymond wrote:
> Raymond and I are in the process of rebuilding OpenOffice with the debug flags, but have run into some errors that didn't occur the first time through in the build. The current error has caused me quite a bit of problems.
>
> We are getting a link error, unrecognized symbol in /svx/source/engine3d/e3dundo.cxx. However the symbol that it is looking for is not present inside e3dundo.cxx. The symbol is "ParagraphData&ParagraphData::operator=(const ParagraphData&)" [sic] which we have located in /editeng/inc/editeng/paragraphdata.hxx and the implementation appears to in /editeng/source/outliner/paralist.cxx.
>
> There are some very odd things going on here.
>
> 1) paragraphdata.hxx is not included in paralist.cxx even though this is where the prototype is declared.
> 2) e3dundo.cxx doesn't seem to use the ParagraphData class at all.
> 3) e3dundo.cxx doesn't seem to include the libraries where these classes are used.
From what I can gather from the relevant parts of that code an OutlinerParaObject constructor has a ParagraphDataVector argument that is default initialized with an empty ParagraphDataVector. I guess the assignment in this default initialization needs ParagraphData's assignment operator.
Maybe removing the default argument for ParagraphDataVector in OutlinerParaObject's constructor helps? This can be done by creating another constructor that takes only one argument.
Most other compilers seem to optimize the assignment operator away even when compiling in debugging mode.
> I want to note that we first started the debug build using multiple processors (-P8) and perhaps that has caused problems in the ordering in which the libraries were compiled and linked. It is conceivable that this problem may be resolved with a complete system clean and rebuild in linear mode, but before we committed to another day of building the product, we wanted to check with you to see if this problem has occurred before, is it recognized or if there is a solution that you could recommend?
I wouldn't vouch for our build systems ordering at such high parallelism levels... if you want to increase parallelism I'd recommend to change from e.g.
build --all -P8
to e.g.
build --all -P2 -- -P4
The first -P is for build's parallelism, the second -P is for dmake's parallelism. I'm too polite to tell what I really feel about these mechanisms...
> We'd appreciate any help or insight you could provide.
I hope the above helps. If not just add the library that provides the missing symbol to the link list.
> P.S. I will be on holiday for the next two weeks and I believe Raymond will be as well so we may be out of communication.
I'll be (mostly) offline for the rest of the year too :-) Merry Christmas and a Happy New Year!
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 09.01.2014 16:47, Steele, Raymond wrote:
> 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
A good find! And indeed [1] also ran into such a problem and defining
that to disable templatized version of std::vector<T>::assign() was a
workaround needed by the SunStudio compiler.
http://trac.osgeo.org/geos/ticket/224
> The compile of sw then began compiling correctly. Any thoughts?
I'd say that all such defines that make boost less aggressive in using
advanced template magic are fine, so don't worry about it. But I'd use
such an option consistently then, not only in one file. I suggest to add a
-D_RWSTD_NO_MEMBER_TEMPLATES=1
into the solaris makefiles in solenv.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Thanks for the information Herbert. We continued looking at this today, but we still have not determined the reason it is crashing. The application crashes at SidebarController::notifyContextChangeEvent in SidebarController.cxx at maRequestedContext =Context {...}. Our debugger says that eEvent is of the value <ERROR>.
Raymond
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Tuesday, January 21, 2014 5:11 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
Hi David,
> I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
>
> Observed Behaviour
> 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
> 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
> 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
> 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
> 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
> 6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
> 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
> 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
> 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
> 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
Hi David,
> I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
>
> Observed Behaviour
> 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
> 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
> 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
> 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
> 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
> 6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
> 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
> 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
> 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
> 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
I haven't fully caught up with everything, but if I had to debug this
I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use
the command
catch throw
to find the throwing code. Is there a similar facility in Solaris Studio?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
Hey,
I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great!
Observed Behaviour
1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects.
2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application.
3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error).
4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system).
5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of "WeakReference<SidebarController> WeakController (this);"
6. This template definition for WeakController uses Reference<Template>::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx.
7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface.
8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference.
9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value <ERROR> stored in the structure.
10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem.
Thanks,
David Meffe
-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org]
Sent: Friday, January 10, 2014 3:29 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 22:48, Steele, Raymond wrote:
> 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.
The crashes in Writer and Calc you are seeing both happen when copy constructing an OUString from one provided by the SidebarController, so the provided string must be bad.
I suggest to set a breakpoint at SidebarController.cxx:257 and examine the rEvent.ApplicationName and rEvent.ContextName whether these are good strings. From the stack I'd say they probably are not. Then go up the stack and check where they come from and why their are bad.
Good luck!
(I'll be away next week, starting this weekend)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
On 09.01.2014 22:48, Steele, Raymond wrote:
> 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.
The crashes in Writer and Calc you are seeing both happen when copy
constructing an OUString from one provided by the SidebarController, so
the provided string must be bad.
I suggest to set a breakpoint at SidebarController.cxx:257 and examine
the rEvent.ApplicationName and rEvent.ContextName whether these are good
strings. From the stack I'd say they probably are not. Then go up the
stack and check where they come from and why their are bad.
Good luck!
(I'll be away next week, starting this weekend)
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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
RE: EXTERNAL: Re: Building comphelper
Posted by "Steele, Raymond" <ra...@lmco.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Posted by Herbert Duerr <hd...@apache.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org