From owner-freebsd-ports@FreeBSD.ORG Tue Nov 23 01:42:04 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 66195106566C for ; Tue, 23 Nov 2010 01:42:04 +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 0E1488FC08 for ; Tue, 23 Nov 2010 01:42:03 +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 <1PKhtS-0001oI-Gn>; Tue, 23 Nov 2010 02:42:02 +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 <1PKhtS-00046c-0b>; Tue, 23 Nov 2010 02:42:02 +0100 Message-ID: <4CEB1BE9.3070902@mail.zedat.fu-berlin.de> Date: Tue, 23 Nov 2010 02:42:01 +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> <4CEAD07F.7060901@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: Tue, 23 Nov 2010 01:42:04 -0000 On 11/23/10 02:14, Andrew W. Nosenko wrote: > On Mon, Nov 22, 2010 at 22:20, O. Hartmann > wrote: >> 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. > > 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). Well, I just compare to xerces-c.so.27 or xerces-c.so.28 (xerces-c2-devel). Both libraries get installed according to the FreeBSD's library naming policy. I do not find any library that is apart from this naming policy in my boxes /usr/local/lib. Old xerces-c ports seem to have some kind of home-brewn build environment, so GNU autotools do not apply and it seems to be easier to come along with the naming policy which is introduced for FreeBSD's libraries. > >> >>> 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 > > Simple don't touch and you will comply! The NAME part here is > "xerces-c-3.1". Not NAME="xerces-c" and VER="3.1" but > NAME="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= >> 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 guess so, but some ports of the FreeBSD ports (i.e. textproc/xalan-c) want xerces-c2 (which is 2.7.0). I try build xalan-c with the new xerces-c3 and see if it can handle the new header and libraries. > > I see three variants: > (1) simple: just mark these ports (c2 and c3) as conflicting, ... in my testcase I did. > (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. ... well, in such a case we converge much to the weird Linux mess, I guess. > (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). ... this would bring up other complications for ports expecting libs and headers at places where the solo installation normally resides. > 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 tend to install it as a unique port with conflicts activated. Hope there are no further conflicts other than xalan-c. > >> >> 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. >> >