SOLVED: Are we using SimpleReferenceObject correctly?
Henrik /KaarPoSoft
henrik at kaarposoft.dk
Sat Feb 9 02:30:30 PST 2013
On 01/29/2013 08:33 PM, Henrik /KaarPoSoft wrote:
> On 01/28/2013 09:00 PM, Henrik /KaarPoSoft wrote:
>> On 01/28/2013 02:22 PM, Michael Stahl wrote:
>>> On 27/01/13 22:55, Henrik /KaarPoSoft wrote:
>>>> building is now stuck at
>>>> [build LNK] Library/libmysqllo.so
>>>> with
>>>> undefined reference to 'typeinfo for salhelper::SimpleReferenceObject'
>>>
>>> it seems that typeinfo is hidden in the salhelper library, the lines are
>>> explicitly commented out (salhelper/source/gcc3.map):
>>>
>>> # _ZTIN9salhelper21SimpleReferenceObjectE;
>>> # _ZTSN9salhelper21SimpleReferenceObjectE;
>>>
>>> on the other hand the wildcard at the beginning should match these:
>>>
>>> _ZTI*; _ZTS*; # weak RTTI symbols for C++ exceptions
>>>
>>> indeed it is exported here:
>>>
>>>>> nm --defined-only --extern-only
>>>>> solver/unxlngx6/lib/libuno_salhelpergcc3.so.3 | grep _ZTI | grep
>>>>> SimpleReferenceObject
>>>> 0000000000208ac0 V _ZTIN9salhelper21SimpleReferenceObjectE
>>>
>>> but the mysql library does not actually use it here:
>>>
>>>>> nm solver/unxlngx6/lib/libmysqllo.so | grep _ZTI | grep
>>>>> SimpleReferenceObject
>>>
>>> despite some objects from that library including that FValue.hxx:
>>>
>>>> grep -r FValue.hxx
>>>> workdir/unxlngx6/Dep/LinkTarget/Library/libmysqllo.so.d
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx \
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx :
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx \
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx \
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx \
>>>> /master/solver/unxlngx6/inc/connectivity/FValue.hxx \
>>>
>>> so the difference seems to be that your gcc does generate typeinfo and
>>> whatnot for a class that is not actually used.
>>>
FValue.hxx is included by many modules in connectivity.
And since it defines (not just declares) a class referencing
SimpleReferenceObject, gcc will emit code for the class
(ORowSetValueDecorator).
The modules in connectivity (e.g. dbase) which are actually using the
class correctly includes salhelper in their .mk file.
However, modules in connectivity (e.g. mysql) which are not actually
using the class do not include salhelper in their .mk file.
So, a legacy linker will see the class and be unable to fulfill the
reference. This seems to be exactly what happened to me.
In order to identify the class as not being used, we need "Link Time
Optimization", which was not enabled in my toolchain.
I have now enabled "Link Time Optimization" in gcc and ld (binutils),
and I am now able to COMPILE LibreOffice!
(I still have 20 failing unittests, and LibreOffice does still not work,
but that will be the subject of another thread).
Michael, thank you very much for your help!
/Henrik
More information about the LibreOffice
mailing list