Re: C++ extensions requiring LIBO_UDK_4.1

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