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 Tue, 17 Dec 2013 22:52:08 GMT

Hebert,

Here is a listing of the files that we modified because the build did not accept a "const"
qualifier when defining a parameter or a member variable. The solution was to simply remove
the "const" at the time to make the build continue. Since the build did not complain, we left
the changes in until the end.

/sideshow/source/inc/shapeimporter.(hxx/cxx) - member variables: mpGroupShape, mxShape, and
mnCount
/svx/source/sidebar/tools/ColorControl.(hxx/cxx) - member function: SetCurrColorSelect
/svx/source/sidebar/tools/ColorPopup.(hxx/cxx) - member function: SetCurrentColor
/sc/source/ui/drawfunc/drawsw2.cxx - member function: Activate
/sw/source/core/uno/unocore/unoportenum.cxx - member typedef: PortionList_t

David Meffe

-----Original Message-----
From: Steele, Raymond 
Sent: Tuesday, December 17, 2013 3:36 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

Just wanted to add  that it appears that the formula and database application are launching,
but not  Text Document, Spreadsheet,  Presentation, or Drawing.

-----Original Message-----
From: Steele, Raymond 
Sent: Tuesday, December 17, 2013 3:31 PM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

Herbert,

At long last Raymond and I have successfully gotten through the entire build script without
a fault. The executable seemed to create just fine and we were able to launch soffice. We
got the splash screen, then the executable started and the options window appeared and everything
looked to be in order, but when we selected one of the document types to open, the executable
crashed with the memory error: 

./soffice[121]: wait: 6980: Memory fault

I don't think Raymond or I was expecting everything to work right on first launch and we were
happy to see the splash screen, the executable start and the option menu appear. However,
have you seen this type of memory error before or has it been seen by others? Do you have
an idea what might cause this?

My fear is that we have made too many modifications to the code in order to get the system
to build correctly. We have removed, in small select areas, "const" as a qualifier to certain
parameters to member functions because the system would not compile with these parameters
declared as a const. We can provide a list of these locations that we have edited, I believe
it is about 3 or 4 files that might have been edited in this way. 

If you have any ideas, it would greatly help us out. Thanks.

David Meffe

-----Original Message-----
From: Herbert Duerr [mailto:hdu@apache.org] 
Sent: Monday, December 16, 2013 4:46 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hi David,

> Your idea worked. We were able to comment out those lines in the prex.h and the system
was able to successfully build the VCL module as well as several others. We can almost taste
the finish line.

Yay! I'm very glad to hear this 8-)

> However we have encountered another problem with the build that is a little more difficult
than just sorting out the included header files and paths, this time in the slideshow module.
The error is located in the c++  /usr/include/stdcxx4/deque.cc on line 569 and states that
ShapeImporter::XShapeEntry has a const member mpGroupShape and cannot be reassigned. We can
see in shapeimporter.cxx that line 181 is indeed a const definition of mpGroupShape, but it
doesn't seem to tie directly to line 569 in deque.cc. This may be because deque.cc may be
used as a template, and the assignment is forbidden because the value in XShapeEntry is a
const, but is there a way around this?

This seems to be caused by a strange interaction of boost's shared_ptr and that const members
can only be set in constructor. Maybe rvalue references come into play here too if your compiler
has them enabled. 
The exact error message could help...

> Do you have a thought as what we might try to continue with the build?

If the problem is in boost's shared_ptr then maybe updating to a later version could help.
Please see my patch in issue 123817 if you want to update to the latest boost.

But maybe the shared_ptr problem is genuine when e.g. the reference counting requirements
of such a shared_ptr require it to be non-const?

Anyway, the quickest workaround would be to remove the const from in line 119 of shapeimporter.hxx
and line 193 of shapeimporter.cxx.

Herbert


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message