discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: question regarding xxx_INTERFACE_VERSION for libraries/frameworks


From: Nicola Pero
Subject: RE: question regarding xxx_INTERFACE_VERSION for libraries/frameworks
Date: Sun, 14 Nov 2010 12:56:43 +0100 (CET)

IIRC, the way you are supposed to use it is:


include $(GNUSTEP_MAKEFILES)/common.make

LIBRARY_NAME = PDFKit

PDFKit_VERSION = 1.0.0
PDFKit_INTERFACE_VERSION = 1.0

...

include $(GNUSTEP_MAKEFILES)/library.make


The 'xxx_VERSION' determines the full library name, eg

 libPDFKit.so.1.0.0

The 'xxx_INTERFACE_VERSION' determines that library version that is linked
into the library, and creates a symlink

 libPDFKit.so.1.0 --> libPDFKit.so.1.0.0

So now applications are linked to libPDFKit.so.1.0, and you can change the
xxx_VERSION freely, but as long as you leave the xxx_INTERFACE_VERSION the same
(and don't actually change the API), applications are happy even if you deploy
a new library version (eg, if you deploy libPDFKit.so.1.0.1 with some bugfixes
but no changes in the API, as soon as you leave the interface version to 1.0,
it can be deployed and be used by all apps, old and new, with no changes).


Now, I think the problem you are having is that one of your port patches (in
the URL you posted, the one for target.make) changes OpenBSD removing all the
symlinks (and also the -soname argument for the linker), so a single file gets 
installed, and interface version is not stored in the library file itself.  
That removes the ability to have libPDFKit.so.1.0 and libPDFKit.so.1.0.0 as 
separate files.

I'm not entirely sure why the symlinks are removed in OpenBSD (presumably 
because
they are a "Linux" thing and you don't want them on OpenBSD); but if you need 
to remove them, a single file gets installed; your problem is probably that you
want the single file installed to be LIB_LINK_SONAME_FILE instead of 
LIB_LINK_VERSION_FILE.
If so, a bit more hacking of target.make for OpenBSD would allow you to install
the file you want ;-)

Thanks

-----Original Message-----
From: "Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de>
Sent: Sunday, 14 November, 2010 12:32
To: discuss-gnustep@gnu.org
Subject: question regarding xxx_INTERFACE_VERSION for libraries/frameworks

Hi,

if I see that right, the variable above is not much used across gnustep
projects. But if I understand the documentation right, I should set it,
to manipulate the major and minor numbers of the shared library, if I
need to do so. If it is empty, the interface version of the
library/framework is derived from the xxx_VERSION variable, or if that
is also not set, then its getting its default value of 0.1.
In OpenBSD ports tree, when importing new libraries, they are usually
imported with interface version 0.0, i.e. libPDFKit.so.0.0, and there
are no symlinks created to libPDFKit.so.0 or libPDFKit.so, since the
linker always searches for library names, suffixed with major and minor
number.
So I specified libXXX_INTERFACE_VERSION=0.0 as make environment like this:

libXXX_INTERFACE_VERSION=0.0 gmake
which did not worked, it still picked up the version from xxx_VERSION.
then I tried it as a flag:
gmake libXXX_INTERFACE_VERSION=0.0
which did not worked, it still picked up the version from xxx_VERSION.
afterwards I patched the GNUmakefile, with the same result.

After a lot of head banging, I found that when I patch
Instance/library.make in the gnumakefile package like the patch below,
then its starting to work as expected. I also added a similar patch to
Instance/framework.make, to make it work for the frameworks.

The patch is against gnustep-make-2.4.0, and I'm also using all latest
stable release versions of gnustep-core. I have to admit, there are some
more patches against gnustep-make in the ports system, but they should
not interfere here. The patches can be found
here:http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/gnustep/make/patches/

Someone, maybe Nicola ;), could tell me whether I do sth. wrong here, or
why it is not working as I think it should do?
Or is this a kind of a bug in gnustep makefiles?

cheers,
Sebastian


--- Instance/library.make.orig  Thu Mar 19 17:59:53 2009
+++ Instance/library.make       Tue Oct  6 20:36:23 2009
@@ -184,7 +184,7 @@ endif
 ifneq ($(BUILD_DLL),yes)
 
 LIBRARY_FILE = $(LIBRARY_NAME_WITH_LIB)$(SHARED_LIBEXT)
-VERSION_LIBRARY_FILE = $(LIBRARY_FILE).$(VERSION)
+VERSION_LIBRARY_FILE = $(LIBRARY_FILE).$(INTERFACE_VERSION)
 SONAME_LIBRARY_FILE  = $(LIBRARY_FILE).$(INTERFACE_VERSION)
 
 else # BUILD_DLL

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep





reply via email to

[Prev in Thread] Current Thread [Next in Thread]