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:h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
