Date: Tue, 23 Nov 2010 03:14:56 +0200 From: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> To: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> 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: <AANLkTiks4YNn37x2u-sonKGwzQOmPQLf9C2xujF4kvsK@mail.gmail.com> In-Reply-To: <4CEAD07F.7060901@mail.zedat.fu-berlin.de> 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> <4CEAD07F.7060901@mail.zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 22, 2010 at 22:20, O. Hartmann <ohartman@mail.zedat.fu-berlin.de> wrote: > 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> =A0wrote: >>> >>> 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> =A0 =A0 =A0wrote: >>>>>> >>>>>>> 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. >>>>>> =A0From >>>>>> 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 install= es >>>>> libxerces-c-3.1.so. >>>> >>>> This not a problem. =A0Inability 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. =A0Please, 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. =A0Like switch from Glib-1.x (libglib.so.x) to Glib-2.x >>>> (libglib-2.0.so.x). =A0In 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. =A0Just >>>> 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. =A0See 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 procee= d >>> 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 i= s > 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. =A0Both uses libNAME.so[.VER]. > > I doubt this, or I do something stupid everytime again and again. Yes. You mess the package version (3.1 oe 3.1.1 in your case) with the ABI version (.0 or empty, in this case AFAIU). > >> 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). =A0But indeed, the NAME in your case _is_ >> "libxerces-c-3.1". =A0I 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 FreeB= SD > uses (libNAME.so.VER). I tried several variations, but it seems that Simple don't touch and you will comply! The NAME part here is "xerces-c-3.1". Not NAME=3D"xerces-c" and VER=3D"3.1" but NAME=3D"xerces-c-3.1" and VER is empty. Again: "3.1" is the part of NAME! > 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= =3D > 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. Again: just don't touch the library name and you will collision free from the library names point of view: xerces-c2 has no libxerces-c-3.1.so. But there lives another problem: Xerces people doesn't expect parallel installation of the "evelopment" part of Xerces-C (headers, pkg-config, etc). At least it seems so by listing the libxerces-c package from Ubuntu. I see three variants: (1) simple: just mark these ports (c2 and c3) as conflicting, (2) semi-simple: split each xerces-c port at the two: run-time and development. Runtime contains a shered library, development contains anything other. Mark development parts as conflictitng. (3) move each port away from each other's way: move headers into own versioned deirectory (e.g. from include/xercesc/ to insclude/xercesc-3.1/xercesc/), drop libxerces-c.so (if any -- I don't know), rename pkg-config (.pc) file, and static library (if any), may be something yet another, like documentation -- need to look at the actual install. All these changes hidden from the users through pkg-config's .pc, therefore only one problem for developers will be changed (non-standard name of the .pc file, i.e. pkg-config's module). But ATM I see no better way to allow parallel installation of the packages that aren't intended for parallel installation by theirs authors... > > 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. > --=20 Andrew W. Nosenko <andrew.w.nosenko@gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTiks4YNn37x2u-sonKGwzQOmPQLf9C2xujF4kvsK>