Re: C++ extensions requiring LIBO_UDK_4.1
On 02/26/2013 03:49 PM, Michael Stahl wrote: it appears for mysqlc just a -DRTL_DISABLE_FAST_STRING is enough to get something that should run already on 3.6 too: master 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) 0x0050: Name: LIBO_UDK_3.6 Flags: none Version: 10 committed in 34faec549ef33f77c4f866a4094d9fcf447025ee But if we build module mysqlc during a LO build, it is due to --enable-ext-mysql-connector, to include the resulting mysql-connector-ooo.oxt as a bundled extension (witness scp2/source/extensions/file_extensions.scp). In which case there is no need for the mysql-connector-ooo.oxt to be backwards compatible. So I think we should either (a) revert the above commit, (b) make it conditional on some new --enable-unbundled-ext-mysql-connector, (c) replace --enable-ext-mysql-connector with --enable-unbundled-ext-mysql-connector (and adapt scp2 accordingly), or (d) shrug shoulders and let a bundled mysql-connector-ooo.oxt be needlessly de-optimized (but augment the above commit with some comment). there seems to be another C++ extension Presentation Minimizer but for that one it didn't help, it still needs LIBO_UDK_4.1 (but i think we bundle this extension so probably not much need to fix that). Indeed. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: C++ extensions requiring LIBO_UDK_4.1
On 26/02/13 12:39, Stephan Bergmann wrote: 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. it appears for mysqlc just a -DRTL_DISABLE_FAST_STRING is enough to get something that should run already on 3.6 too: master 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) 0x0050: Name: LIBO_UDK_3.6 Flags: none Version: 10 committed in 34faec549ef33f77c4f866a4094d9fcf447025ee there seems to be another C++ extension Presentation Minimizer but for that one it didn't help, it still needs LIBO_UDK_4.1 (but i think we bundle this extension so probably not much need to fix that). ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
C++ extensions requiring LIBO_UDK_4.1 (was: Re: Mysql Connector Extension Size Confusion)
On 22/02/13 15:53, Alexander Thurgood wrote: Le 22/02/2013 15:42, Fridrich Strba a écrit : Hi Fridrich, Did you try whether it works? Maybe the question is only moot. Just saying. F. 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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: C++ extensions requiring LIBO_UDK_4.1
Le 22/02/2013 16:30, Michael Stahl a écrit : 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. Two questions, both of which may be dumb, because I don't really know what is going on here, but : Shouldn't it default to the lowest common denominator, i.e. 3.6 ? Is this only a problem with symbol-enabled builds ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: C++ extensions requiring LIBO_UDK_4.1
On 22/02/13 16:41, Alex Thurgood wrote: Le 22/02/2013 16:30, Michael Stahl a écrit : 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. Two questions, both of which may be dumb, because I don't really know what is going on here, but : Shouldn't it default to the lowest common denominator, i.e. 3.6 ? well it's based on the symbols that are actually required but not defined in the mysql extension library, i.e. LO/URE functions called and misc. typeinfo/RTTI stuff. i suspect (but haven't checked) that due to changes to the OUString class the existing code now implicitly calls and requires different functions that did not exist in older versions. Is this only a problem with symbol-enabled builds ? the term symbol is quite overloaded; this is about linker symbols in shared libraries, which may be exported from library A and imported in library B. has nothing to do with --enable-symbols or --enable-debug configure options. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
