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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
