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


_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to