From owner-freebsd-ports@FreeBSD.ORG Fri Nov 19 17:41:38 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 D60C6106564A for ; Fri, 19 Nov 2010 17:41:38 +0000 (UTC) (envelope-from andrew.w.nosenko@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2348FC18 for ; Fri, 19 Nov 2010 17:41:38 +0000 (UTC) Received: by qwi4 with SMTP id 4so95686qwi.13 for ; Fri, 19 Nov 2010 09:41:37 -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=F8zKKKWh5kJCBilkYVvBud7+o1vdVgC8gQpSFYpuY5g=; b=TFhX6NAvmcJSKJHcj9yVCnPY3P6E0djp+FQRqwTtMx/HcrT9AS3uZ8IC1FgFNnEYuW PctzguXpjgPy3bF3ul5KLq8jyr66b/vP0G3cSJa3NSDbiWo2fmkHQcN9Svi/MWQ3a/WY hCFBncqyAukqX80nSrQGCGbudUmiO8t4nzmH0= 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=kKO+G5OTbFDywmCiT+4X1EdqLWYcvYNmrsiUnjRyCgDEf71U5oqYbBFOg7y5fqnUgm AkyX8ZaH87f9L61oHHaSEbfVjdcThxOONgeO4sWDDCQulDP2jIuV/z9QkjvBi5wuC50H spKhK0+PA8fcvBv3Ub/MN1N4VVfDJQNhnM2EM= MIME-Version: 1.0 Received: by 10.229.246.79 with SMTP id lx15mr2000329qcb.30.1290186672562; Fri, 19 Nov 2010 09:11:12 -0800 (PST) Received: by 10.229.95.209 with HTTP; Fri, 19 Nov 2010 09:11:12 -0800 (PST) In-Reply-To: <4CE683D1.1020300@zedat.fu-berlin.de> References: <4CE66051.7000600@zedat.fu-berlin.de> <20101119134636.2c5f44cc@headache.rainbow-runner.nl> <4CE683D1.1020300@zedat.fu-berlin.de> Date: Fri, 19 Nov 2010 19:11:12 +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 , 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: Fri, 19 Nov 2010 17:41:39 -0000 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" =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.htm= l >> 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! --=20 Andrew W. Nosenko