fwd: Re: [porting-dev] 644 issues
Good news folks. I just noticed this on the upstream mailing list.
This is bringing some of the OOo shared library names in line with the
<libraryname>.so.<version> naming convention found in /usr/lib.
Chris
----- Forwarded message from Matthias Huetsch <matthias.huetsch@sun.com> -----
Date: Sat, 08 Feb 2003 16:32:21 +0100
From: Matthias Huetsch <matthias.huetsch@sun.com>
Subject: Re: [porting-dev] 644 issues
To: dev@porting.openoffice.org
Hi Volker, Kevin,
What ever is wrong in 'product' with 'salhelper' and 'cppuhelper' on
Windows, please don't change the naming of that libraries but fix
'product' to pack the correct ones.
Yes, the naming of 'salhelper' and 'cppuhelper' has changed since OOo
1.0.x, but for a good reason and that is Application Binary Interface
(ABI) stability.
For all our Unix platforms, both libraries now conform to the UDK shared
library versioning, i.e. they look like
$(TARGET)$(COMID).so.$(UDK_MAJOR).$(UDK_MINOR).$(UDK_MICRO)
and export an (ELF) 'SONAME' of
$(TARGET)$(COMID).so.$(UDK_MAJOR)
just like the other UDK libraries with C binding (i.e. exporting a C
API, only).
As such shared library versioning happens to not exist under Windows, we
choose to keep their 'mangled only' names for Windows.
If you take a close into the 'salhelper' and 'cppuhelper' makefile.mk's,
there is code like this at the top:
.IF "$(OS)" != "WNT"
UNIXVERSIONNAMES=UDK
.ENDIF # WNT
and further below the code that you quoted:
.IF "$(UNIXVERSIONNAMES)" != ""
SHL1TARGET= $(TARGET)$(COMID) # versioned name
.ELSE
SHL1TARGET= $(TARGET)$(UDK_MAJOR)$(COMID) # mangled name
.ENDIF # UNIXVERSIONNAMES
If 'product' makefiles don't conform to this definition, they need to be
fixed, but the the definition.
Hope that helps,
Matthias
Volker Quetschke wrote:
>Hi Kevin,
>
>>Arggh that means there is no single solution for both.
>
>
>My build finished product after the changes/rebuild of sal|cppu-
>helper. I'm stuck in connectivity due to bison, but until there
>it works.
>
>>On Linux/Unix the cppuhelper and salhelper now builds the following
>>files:
>>
>>libcppuhelpergcc3.so and libsalhelpergcc3.so (under 102 they were
>>named libcppuhelper3gcc3.so and libsalhelper3gcc3.so
>>
>>So the name convention in 644 seems to
>>$(MY_DLLPREFIX)cppuhelper$(COMID)$(MY_DLLPOSTFIX)
>>This is what Juergen's SDK patch for 102 actually changed the
>>incorrect OOo102 names to under Unix.
>>
>>Has there been any change under WIN in the names given to the
>>cppuhelper and salhelper routines?
>
>No, but my change:
>
>SHL1TARGET=$(TARGET)$(UDK_MAJOR)$(COMID) -> SHL1TARGET=$(TARGET)$(COMID)
>
>worked. (It's a change only for Winnt, unix had this already)
>
>>The 644 solenv/inc/libs.mk uses the following:
>>
>>libs.mk:CPPUHELPERLIB=-lcppuhelper$(COMID)
>>libs.mk:CPPUHELPERLIB=$(LIBPRE) icppuhelper.lib
>>
>>So if the WIN names are unchanged since OOo102 for those libs/files
>>then we will need to ifdef the product/util/makefile.mk changes I made
>>so that it works for both.
>
>Only if there is a reason for not using SHL1TARGET=$(TARGET)$(COMID)
>also for Win.
>
>>I would ask Juergen to tell you the official name for that lib in the
>>SDK. My guess is you should simply ifdef the change I made in
>>product/util/makefile.mk and not change the salhelper and cppuhelper
>>makefile.mk files.
>
>Oh, I see, if library names given in the SDK have to stay the samen,
>then you're right. But I would perfer a similar naming for all
>platforms.
>
>Volker
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@porting.openoffice.org
For additional commands, e-mail: dev-help@porting.openoffice.org
----- End forwarded message -----
--
Reply to: