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