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