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, 07 Jan 2014 22:11:34 GMT
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


Mime
View raw message