From owner-freebsd-ports@FreeBSD.ORG Mon Nov 22 18:20:30 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 B3CD91065674 for ; Mon, 22 Nov 2010 18:20:30 +0000 (UTC) (envelope-from andrew.w.nosenko@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82A8F8FC19 for ; Mon, 22 Nov 2010 18:20:30 +0000 (UTC) Received: by pvc22 with SMTP id 22so1750411pvc.13 for ; Mon, 22 Nov 2010 10:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ABBs3r3B2k25CDzKE/GYp6WrfvjaK+E6e9yoVCLbQmE=; b=YWpX1lM9ecSrFVKn1HthfZnKHoaXv+p38H714Jht4djDWEOnXhM12l0bYmTvyRqKEl /RW3jMKcaQu0qlkSjl8Yi33opJcyh3wT8u+TW3UjMGA97JfBU8jfKOvv4JxBA/+o15Mb kinUeg/+gD4ndytE62imLsEz7uI77RlQNs8gM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mMnH0TOmAlfvvSo7foikORG8pSWCJBBg4wLujakLxBR9HuWn0YYnIs7aeOKx42RWb7 3cPavl5jPB8PKXxhJMXPkjs2AU4aOvFASFkfpVAvaXd3x3wQ4JePfX8aQABZP7nm8jbj kLd750Im5VvPFe5Z0Ayvj/8apWeo9OTOrRUV0= MIME-Version: 1.0 Received: by 10.229.246.79 with SMTP id lx15mr5317250qcb.30.1290450028881; Mon, 22 Nov 2010 10:20:28 -0800 (PST) Received: by 10.229.95.209 with HTTP; Mon, 22 Nov 2010 10:20:28 -0800 (PST) In-Reply-To: <4CE6B3D5.5040101@mail.zedat.fu-berlin.de> 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> Date: Mon, 22 Nov 2010 20:20:28 +0200 Message-ID: From: "Andrew W. Nosenko" To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Koop Mast , "O. Hartmann" , 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 18:20:30 -0000 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" =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 th= is >>>>> 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.h= tml >>>> 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. =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. See below. > I'd like to come along with FreeBSD's library naming scheme when installi= ng > the library into /usr/local/lib. I thought manipulating the > source-environment when compiling would be the least-efford way, but I se= e, > maybe it would be easier to come along with a post-install: target by sim= ply > moving and making a symbolic link. If so, I need to detect by the framewo= rk > 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 ... Ineed it's simple not true. Both uses libNAME.so[.VER]. 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. --=20 Andrew W. Nosenko