C++ extensions requiring LIBO_UDK_4.1
Stephan Bergmann
sbergman at redhat.com
Tue Feb 26 03:39:14 PST 2013
On 02/22/2013 04:30 PM, Michael Stahl wrote:
> On 22/02/13 15:53, Alexander Thurgood wrote:
>> All I know is that the "new gbuild" one doesn't work on other people's
>> systems, as I have made the connector available for download from my
>> Dropbox account (both 32bit and 64bit Linux versions) for testing
>> purposes. It works on my own dev-install build.
>
> it's possible that this is because it requires functions that were added
> after the 4.0 release on master (i suspect this happens automatically
> due to some OUString changes); for example here i'm getting a dependency
> on LIBO_UDK_4.1 symbol version, which none of the current releases supply.
>
>> > readelf --version-info /work/lo/master/solver/unxlngx6/lib/mysqlc.uno.so | grep LIBO_UDK
>> 01c: a (LIBO_UDK_3.6) 4 (UDK_3_0_0) 2 (UDK_3_0_0) 4 (UDK_3_0_0)
>> 08c: 12 (LIBO_UDK_4.1) 7 (UDK_3_0_0) 4 (UDK_3_0_0) b (CXXABI_1.3)
>> 0x0030: Name: LIBO_UDK_4.1 Flags: none Version: 18
>> 0x0060: Name: LIBO_UDK_3.6 Flags: none Version: 10
>
> i'm not sure if this affects only extensions built with LO build system
> or also those build with ODK.
As always, the best advice if you want something that works back with an
old version is to build it against that old version's source resp. SDK.
That said, one gotcha indeed is that even if you do not use any new
functionality, just recompiling C++ sources in a recent LO build can
introduce dependencies on new symbols. One example is an expression
s1 + s2
with two OUString instances, which now goes via inline OUStringConcat
and an inline OUString(OUStringConcat const &) ctor that calls
rtl_uString_alloc that is new with LIBO_UDK_4.1, i.e., LO 4.1.
The good news, at least for that example and at least for now, is that
all that new functionality is conditional on RTL_FAST_STRING, which is
not (yet?) set when building against the SDK.
Stephan
More information about the LibreOffice
mailing list