Apache OpenOffice (AOO) Bugzilla – Issue 11230
comphelp2 library needs to renamed into comphelp3$(COMID)
Last modified: 2004-04-26 19:25:04 UTC
Module util/comphelper provides a shared library that exports C++ symbols, and does not provide a stable ABI (via mapfile or *.def file). The 'comphelp2' library (libcomphelp2.so, comphelp2.dll) of SRC641 (OOo 1.0.x, SO 6.0) and that of SRX644 (OOo 1.1, SO 6.1) are not binary compatible, as the current (unchanged) library name suggests. Thus, at a minimum, COMPHLP_MAJOR (defined in util/comphelper/version.mk) needs to be incremented from 2 to 3. In addition, as this is a C++ library, the used compiler needs to be encoded in the name as well (as other well behaved C++ libraries already do, e.g. on win salhelper3MSC.dll, cppuhelper3MSC.dll, ucbhelper2MSC.dll). The new library name thus needs to be comphelp$(COMPHLP_MAJOR)$(COMID). Internal bug #106136# is blocked until this issue is fixed. Issue will be fixed in 'cws_srx644_mhu01'.
Fix needed for Target Milestone 'OOo 1.1 Beta'.
Files modified: solenv/inc/libs.mk comphelper/version.mk comphelper/util/makefile.mk scp/source/global/setupzip.scp Will provide file revisions after integration.
Fix integrated into OOo 1.1 master workspace (with cvs tag: SRX644_m4), thus closing this issue. Files modified: solenv/inc/libs.mk, r1.59.2.1 comphelper/util/makefile.mk, r1.3.14.1 comphelper/version.mk, r1.1.1.1.46.1 scp/source/global/setupzip.scp, r1.96.4.1
Matthias, Ocke just pointed out that there's more than this: In connectivity, there is a library called dbtools2, which is also affected (there are a lot of other *2* libs, too, but they only export the standard UNO entry points). What needs to be done to change this, too?
Hi Frank, Ocke, The changes necessary for connectivity (dbtools2 et al) are completely analogous to the changes I've done for comphelper. There is only one thing I forgot: comphelper/prj/d.lst, r1.6.36.1 to deliver 'comphelper/version.mk', included in 'solenv/inc/libs.mk'. For the rationale behind this, my initial comments when submitting this issue should be sufficient. Just a short summary: 1) when exporting a stable C API, use true versioning, as with basic UDK libraries (e.g. libsal.so.3.1.0, libcppu.so.3.1.0, ...) 2) when exporting a stable C++ API (and importing stable APIs, only), use true versioning as well (e.g. libcppuhelper$(COMID).so.3.1.0, ...) or at least 'name mangling' as with this comphelp case, i.e. libcomphelp$(COMPHLP_MAJOR)$(COMID).so 3) when exporting or importing an unstable API, stay with our traditional 'lib<whatever>$(UPD)$(DLLPOSTFIX)' scheme, e.g. your 'libdba644li.so'. Hope this helps, Matthias
re-opening for the analogous problem in connectivity
Ocke, can you please care for this in the 1.1 Beta 2 timeframe? If I understand Matthias correctly, we also need to change the following: * change the name of the dbtools lib to include the UPD * change the names of the drivers (except dBase and file, which already contain an UPD) to contain a new version (3 instead of the current 2) Matthias, where can one read such guidelines for library names, except in a bug to accidentally stumble upon?
I'll care for
Please care for if you got the time. Thx.
I think we're not able to deal with this in the 1.1Beta time frame anymore. One of the problems (and the reason why the fix we already had was revoked) is that some of the affected libraries are loaded dynamically in various places, and the name change has to be made in these places, too, but we didn't find a safe (and error-proof) way to do this.
accepting
Huh? Why the heck should this block issue 21783 (which is the tracking bug for ms interop)?
the comphelper lib has recently been renamed by AS - comphelper4$(COMID) is now part of SRC680. I am separating the dbtools-part, to not mix those two things up here: issue 28385 is about renaming the dbtools library according to the rules sketched by MHU above.
closing