Are we using SimpleReferenceObject correctly?

[Henrik /KaarPoSoft]

On 01/28/2013 02:22 PM, Michael Stahl wrote:
> On 27/01/13 22:55, Henrik /KaarPoSoft wrote:
>> Dear all,
>>
>> As described in the mailing-list-thread
>> Issues building LibreOffice 4.0.0.1
>> http://lists.freedesktop.org/archives/libreoffice/2013-January/044838.html
>> I am trying to build and package LibreOffice 4.0.0.* for KaarPux
>> http://kaarpux.kaarposoft.dk/
>>
>> I am starting a new mailing-list thread here to try to address
>> one issue at a time.
>>
>> With LibreOffice 4.0.0.2, Stephans patch
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=d71e8fb17bd008751909ef2fabc6ff4f1e2db187
>> no other pathes and the configuration attached as "config.txt"
>> 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.
>

THANK YOU VERY MUCH for this excellent technical insight.

My gcc is build with those configure options:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix= --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
--enable-languages=c,c++ --disable-multilib --disable-bootstrap 
--with-system-zlib --with-pkgversion=KaarPux
Thread model: posix
gcc version 4.7.2 (KaarPux)

Looking at ArchLinux and Fedora, I have now rebuild gcc with those 
additional settings:
--disable-libunwind-exceptions
--enable-gnu-unique-object
--enable-linker-build-id
--with-linker-hash-style=gnu
although it is not clear to me if those settings would make any 
difference regarding this problem.

I have looked at http://gcc.gnu.org/install/configure.html
but nothing rings a bell, and RTTI is not mentioned there.

I will revert here on the list with build results for LO with my new gcc.

Again: Thank you very much for pointing me in the right direction

/Henrik