Date: Mon, 22 Nov 2010 21:20:15 +0100 From: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> To: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> Cc: Koop Mast <kwm@rainbow-runner.nl>, freebsd-ports@freebsd.org Subject: Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes? Message-ID: <4CEAD07F.7060901@mail.zedat.fu-berlin.de> In-Reply-To: <AANLkTikJ3KMz-9ZqTuEOjc-_NzqxunVowSHZN6Vnv3G8@mail.gmail.com> References: <4CE66051.7000600@zedat.fu-berlin.de> <20101119134636.2c5f44cc@headache.rainbow-runner.nl> <4CE683D1.1020300@zedat.fu-berlin.de> <AANLkTimHsAqRBndpqLvuL7GC-Hiu4o85dtTJfZky0%2BO-@mail.gmail.com> <4CE6B3D5.5040101@mail.zedat.fu-berlin.de> <AANLkTikJ3KMz-9ZqTuEOjc-_NzqxunVowSHZN6Vnv3G8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/22/10 19:20, Andrew W. Nosenko wrote: > On Fri, Nov 19, 2010 at 19:28, O. Hartmann > <ohartman@mail.zedat.fu-berlin.de> wrote: >> On 11/19/10 18:11, Andrew W. Nosenko wrote: >>> >>> 2010/11/19 O. Hartmann<ohartman@zedat.fu-berlin.de>: >>>> >>>> On 11/19/10 13:46, Koop Mast wrote: >>>>> >>>>> On Fri, 19 Nov 2010 12:32:33 +0100 >>>>> "O. Hartmann"<ohartman@zedat.fu-berlin.de> wrote: >>>>> >>>>>> Hello. >>>>>> Trying to do my first port and run into trouble. >>>>>> The software package (Xerces-c 3.1.1) comes with a full autotoll >>>>>> environment and so far building and installing works. >>>>>> >>>>>> But the libarary name is "libxerces-c-3.1.so" and I need to change this >>>>>> to respect the FreeBSD nameing schemes to "libxerces-c.so.31". I'm >>>>>> looking for a way avoiding some "post-install:" stuff. >>>>> >>>>> There isn't any problem with the libxerces-c-3.1.so name. >>>>> From http://www.freebsd.org/doc/en/books/porters-handbook/special.html >>>>> Try to keep shared library version numbers in the libfoo.so.0 format. >>>>> Our runtime linker only cares for the major (first) number. >>>> >>>> Well, this is the problem. The automated installation process installes >>>> libxerces-c-3.1.so. >>> >>> This not a problem. Inability to catch the libxerces-c-3.1.so by >>> specifying -lxerces-c linker flag (and enforce you to specify >>> -lxerces-c-3.1) is intended and desired effect. Please, don't touch >>> the library name. >>> >>> Usually, authors change library name if want to ensure and express >>> complete API and ABI break without any forward and backward >>> compatibility. Like switch from Glib-1.x (libglib.so.x) to Glib-2.x >>> (libglib-2.0.so.x). In both your (libxerces) and my (libglib) >>> examples the authors desired to use "interface generation" numbers, >>> but it just for aesthetics reasons, indeed the libraries could be >>> renamed to any other arbitrary way (for example, libNewGlib.so and >>> libEvenBetterXerces.so -- ideologically and technically there no >>> differences). >>> >>> If you rename libxerces-c-3.1.so to libxerces-c.so.31, then all >>> application that want and expect the old "zero-generation" API and >>> link against '-llibxerces-c' will fail because will catch absolutely >>> unexpected (by them) and incompatible libxerces-c-3.1 API. >>> >>> Applications that indeed want and expect libxerces-c-3.1 API, and >>> therefore that links with '-llibxerces-c-3.1' will fail also. Just >>> because there no more libxerces-c-3.1.so library -- it was renamed to >>> unexpected name w/o good reasons. >>> >>> Conclusion: Please, don't touch library names! >>> >> >> Well, maybe here is a misunderstanding. > > Sure. See below. > >> I'd like to come along with FreeBSD's library naming scheme when installing >> the library into /usr/local/lib. I thought manipulating the >> source-environment when compiling would be the least-efford way, but I see, >> maybe it would be easier to come along with a post-install: target by simply >> moving and making a symbolic link. If so, I need to detect by the framework >> what the lib vendor has choosen as thi lib name, to automate the proceed >> perfectly. Is this possible? >> > > Seems, like you think that Xerces authors use libNAME-VER.so naming > scheme, while FreeBSD uses libNAME.so.VER ... Well, after building a vanilla xerces-c version 3.1.1 and checked the vendor's point of view how the lib should be named, I guess my thinking is right about libNAME-VER.so. Simply try download and compile/install the sources from http://xerces.apache.org/xerces-c/. > > Ineed it's simple not true. Both uses libNAME.so[.VER]. I doubt this, or I do something stupid everytime again and again. > Usually, libNAME.so.VER with greatest VER symlinked to libNAME.so. > How VER represented (it just a number, or more complicated like .N, > .N.M., .N.M.K... -- depends on the ld.so implementation on the target > system and usually should not bother you as software author (if you > use Libtool, which is good in job of hiding differences between > systems in that respect). > > Also, these .N[.M[.K]] represent the ABI version of library and has > nothing with package version. > > Just in the case of Xerces, the NAME contains digits that looks like > version (version of package). But indeed, the NAME in your case _is_ > "libxerces-c-3.1". I unable to say what ABI version VER is without > building Xerces-C, or upstream authors decided to left it empty > indeed, sorry. > The new xerces-c 3.1.1 comes with a whole/complete autotools-environment. There is a m4-folder containing libtool.m4. I tried to patch this in the section "freebsd-elf*" and "freebsd-*" to reflect the naming scheme FreeBSD uses (libNAME.so.VER). I tried several variations, but it seems that something from the ports toplevel Makefile isn't triggering a reconfiguration the right way. I did the same with the toplevel ./configure file which already contains the libtool.m4-macro substitutions, but again, it doesn't seem to be possible to change the libname that gets installed. I tried forcing triggering a aclocal/autoconf procedure via USE_AUTOTOOLS= butthis results surprisingly in a linker error. My intention is to manipulate the installed library and the symbolic link that way that it is clean in the sense of low complication post-install manipulations. xerces-c and xerces-c2 are already in the ports collection and I need a collision-free xerces-c3, so renaming the installed library is important. I thought I could pass some environment variables to the autotool environment when building via a port's top level Makefile, but this seems to be impossible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CEAD07F.7060901>