Re: question regarding xxx_INTERFACE_VERSION for libraries/frameworks

[Sebastian Reitenbach]

Hi,

thank you for you explanation, see my comments below:

Nicola Pero wrote:
> 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 removed the -soname argument when linking the library, since I ran
into problems, let me explain:
With the OpenBSD ports system, after everything compiled, and is
installed in the fake root directory, I run the "make
port-lib-depends-check" command. This checks all binaries and library
files in the given port, against which external libraries the port
links. Afterwards I can then add those to the dependencies for the port.
This is to make sure that pkg_add pulls in all dependencies, and if I
specify minimum major versions of the library files, it will
automatically update the ports it depends on, in case there are older
versions installed. I specifically had the problem with SOGo, and
libSOGo. -Wl,-soname linked libSOGo.so.0 instead of libSOGo.so.0.0 into
the library file. IIRC, The port-lib-depends-check, actually runs a
objdump -p against a library file, and then it checks whether it can
find the libraries listed in the Dynamic Section as NEEDED, in the port
itself, or in the ports listed as dependencies. But since it only checks
the file names of those files, and not what might be linked into it, it
was always whining, since there was no file libSOGo.so.0.
I.e. the version of the library is considered to have nothing to do with
the version of the interface.


> 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); 
Yes, you are right with your assumption here, its jut not wanted on
OpenBSD the installation of a single file is by intention, without all
those symlinks.
In the ports system, the .so.MAJOR.MINOR versions are managed by the
ports system. Its the responsibility of the packager to decide when a
minor or major bump of the version is needed. When the new version of
the library only contains bug fixes, but the interface did not changed,
then nothing is bumped, and the new version will just overwrite the old
file.
When a port gets updated, and the library now provides a new function,
then the minor version is bumped.
When the update is installed, all the ports that link against it, are
still happy, and will just pick up the new file. When a port get
updated, where an updated library gets the interface of a function
changed, or some functions are removed, then a bump of the major number
is needed. With a major bump, all dependent ports linking against that
library, needs to get recompiled, since the linker will not pick it up.


> 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 ;-)
>   
This is a good hint. I'll try that out, removing the patches to the
library.make and framework.make and change the patch of the target.make
file.

I'll let you know how it works out.

thanks,
Sebastian

> 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
>
>
>