From owner-freebsd-ports@FreeBSD.ORG Mon Nov 22 20:20:19 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AFAB106564A for ; Mon, 22 Nov 2010 20:20:19 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 322958FC24 for ; Mon, 22 Nov 2010 20:20:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PKcs4-0001pI-PB>; Mon, 22 Nov 2010 21:20:16 +0100 Received: from e178041165.adsl.alicedsl.de ([85.178.41.165] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PKcs4-0006Lp-71>; Mon, 22 Nov 2010 21:20:16 +0100 Message-ID: <4CEAD07F.7060901@mail.zedat.fu-berlin.de> Date: Mon, 22 Nov 2010 21:20:15 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Andrew W. Nosenko" References: <4CE66051.7000600@zedat.fu-berlin.de> <20101119134636.2c5f44cc@headache.rainbow-runner.nl> <4CE683D1.1020300@zedat.fu-berlin.de> <4CE6B3D5.5040101@mail.zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.41.165 Cc: Koop Mast , freebsd-ports@freebsd.org Subject: Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 20:20:19 -0000 On 11/22/10 19:20, Andrew W. Nosenko wrote: > On Fri, Nov 19, 2010 at 19:28, O. Hartmann > wrote: >> On 11/19/10 18:11, Andrew W. Nosenko wrote: >>> >>> 2010/11/19 O. Hartmann: >>>> >>>> On 11/19/10 13:46, Koop Mast wrote: >>>>> >>>>> On Fri, 19 Nov 2010 12:32:33 +0100 >>>>> "O. Hartmann" 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.