From owner-freebsd-ports@FreeBSD.ORG Sun Feb 22 18:32:30 2009 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 0C8B3106566B for ; Sun, 22 Feb 2009 18:32:30 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47]) by mx1.freebsd.org (Postfix) with ESMTP id BA27C8FC21 for ; Sun, 22 Feb 2009 18:32:29 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090222183228.KHAG4139.eastrmmtao105.cox.net@eastrmimpo03.cox.net>; Sun, 22 Feb 2009 13:32:28 -0500 Received: from localhost ([68.103.37.153]) by eastrmimpo03.cox.net with bizsmtp id qil71a00W3JFCbG02il80N; Sat, 13 Dec 2008 13:45:08 -0500 X-Authority-Analysis: v=1.0 c=1 a=w7AQFoAdmqEA:10 a=qj9uwJrD-0AA:10 a=VVlED5B4AAAA:8 a=6I5d2MoRAAAA:8 a=kviXuzpPAAAA:8 a=04yAYnP23Xp9oO5UD8AA:9 a=TlEXYrFRWe3s_qJjXokA:7 a=Hx41Cw0Pm3UOCZFFdBY6pUoUSMoA:4 a=LY0hPdMaydYA:10 a=BFDKbZatV3MA:10 a=SV7veod9ZcQA:10 a=4vB-4DCPJfMA:10 a=XFXWkDwOaydoZRly:21 a=Hm2FXIzmWN2fBrMY:21 X-CM-Score: 0.00 Date: Sun, 22 Feb 2009 12:32:12 -0600 To: "Thomas Schmitt" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20090222093452.31721928ruovf3gk@webmail.leidinger.net> <102368789721915@212.46.126.165> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <102368789721915@212.46.126.165> User-Agent: Opera Mail/9.63 (Linux) Cc: freebsd-ports@freebsd.org Subject: Re: Problem with .so numbering on FreeBSD in contrast to Linux 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: Sun, 22 Feb 2009 18:32:30 -0000 On Sun, 22 Feb 2009 03:16:21 -0600, Thomas Schmitt wrote: > Hi, > > Alexander Leidinger wrote: >> > which i believe complies to policies-shlib.html. >> I think this is a little bit outdated. We only have one number after >> the .so >> since a long time. All libs in /lib and /usr/lib are .so.X and for 3rd >> party >> applications most are .so.X (those which aren't are a sign of bugs in >> the >> ports collection). > > So this is really a feature. Ahum. > > What is the meaning of that single number ? > Shall it be incremented with each new release > or shall it be kept stable until ABI backward > compatibility gets broken ? Correct, when the ABI changes then bump +1 number. It does not make any sense to force anyone to rebuild all applications to get relink when there is no ABI breaks. > I.e. shall i produce > libburn.so.4 > with each release, > or shall i produce > libburn.so.27 > libburn.so.29 > libburn.so.31 > where Linux would have 4.23.0, 4.25.0, 4.27.0 > and let .so.4 applications start with any of those. > > A compatibility check at run time is part > of the libburn API specs. So the applications > are supposed to be able to detect feature sets > that are too old for their needs. The API can be check version inside the *.pc file by via configure. Like if the configure checks 'pkg-config --modversion foo-1' and if it's lower than what configure wants then output an error for need to update libfoo. It's what all other applications do like GTK+2, pango, cario and etc. For example, in gedit's configure.ac has: --------------------------------------------- PKG_CHECK_MODULES(GEDIT, [ sm >= 1.0.0 libxml-2.0 >= 2.5.0 glib-2.0 >= 2.13.0 gthread-2.0 >= 2.13.0 gio-2.0 >= 2.16.0 gtk+-2.0 >= 2.13.0 gtksourceview-2.0 >= 2.2.0 gconf-2.0 >= 1.1.11 ]) --------------------------------------------- Or/and use the header (*.h) to check API stuff. I don't do C programming very well, so.. dunno. > I.e. libburn.so.4 would be technically ok. > > My question is about the FreeBSD conventions > in order to be friendly to my port maintainer > and to sysadmins. You can keep patch in tarball if you want to. But you don't really need to do that and you can tell your port mainainer to add ltverhack in libburn port. Unitl libtool has the fix then none of that will be need. As for the libtool2 that still doesn't has fix. Yes, I guess, someone will have to report to libtool2. I think the libtool developers knew, but don't know why no action take. Cheers, Mezz > Myself wrote: >> > Maybe the FreeBSD community should discuss this >> > with the GNU libtool project. > Alexander Leidinger wrote: >> On one of my systems 1.2% are not .so.X: > > Well, it looks like rather the online handbook needs > to be discussed first. > > For now i have to ask the bystanders here > for their opinions. > > > Have a nice day :) > > Thomas > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org