From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 14 18:18:49 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1B1106566B for ; Wed, 14 Apr 2010 18:18:49 +0000 (UTC) (envelope-from salfrancl.listas@gmail.com) Received: from mail-bw0-f214.google.com (mail-bw0-f214.google.com [209.85.218.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3458FC1A for ; Wed, 14 Apr 2010 18:18:45 +0000 (UTC) Received: by bwz6 with SMTP id 6so430992bwz.13 for ; Wed, 14 Apr 2010 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=SxscQqdVgCvyzCPnhWtVcEDD+r9Ojrcdg35eAqz6giU=; b=axfcxfxX9ryferv+/swrCQSPgB/9JM2xZElMCLcbVDJ6ZBeWMXqr2lyOTx0fUPIgAc a3Sd8OXnOx5UzELQcS2A9BAdCsxOv9ti2Qz0julaRcaX6x0aV3NpMRIQknZwFVDpMxWl qbkzSqe2sF9/w0FksoL/TA1tNKrsRJPyurSPM= 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 :content-type:content-transfer-encoding; b=v+Vlsglh6NduLfKn2037NL/c/ZjpEdXWRi36yPT5X6wl6UoO0B3krG/JQf/cHoE1Mh 7yL+NW1WTvPSxUV30u5jSGsKzJNoNtafnr7ZMafBv+wnImvNbhfUXbrtEJWCje+pmiR7 ZMUsVmdiKz2eIoq4rEo+vwB87aofOkMsYejT8= MIME-Version: 1.0 Received: by 10.204.122.74 with HTTP; Wed, 14 Apr 2010 11:18:40 -0700 (PDT) In-Reply-To: <20100414174853.GC43908@dan.emsphone.com> References: <20100414174853.GC43908@dan.emsphone.com> Date: Wed, 14 Apr 2010 14:18:40 -0400 Received: by 10.204.6.73 with SMTP id 9mr5580115bky.143.1271269120622; Wed, 14 Apr 2010 11:18:40 -0700 (PDT) Message-ID: From: Leinier Cruz Salfran To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: there is a way to avoid strict libraries linking? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 18:18:49 -0000 On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson wrote= : > In the last episode (Apr 14), Leinier Cruz Salfran said: >> i want to know if there is a possibility to avoid current strict librari= es >> linking .. =C2=A0i will explain myself >> >> for example .. i have installed 'gtk' (2.18) that depends on library >> 'libpng.so.5' (png) .. =C2=A0and i will upgrade 'png' port to a superior >> version that install the library 'libpng.so.6' BUUUTTTT 'gtk' will not b= e >> upgraded, so it will still depending on 'libpng.so.5' .. =C2=A0so here i= s my >> question: there is a way to avoid this?????? =C2=A0i means that 'gtk' lo= ad >> 'libpng.so' (that is a symbolic link to 'libpng.so.6') instead of >> 'libpng.so.5' at runtime > > The whole reason for a library version bump is because the libraries are = not > compatible with each other, usually due to a function being removed or it= s > argument list changing, or a structure changing size. =C2=A0Symlinking on= e > version onto another version might work, but only if the application does= n't > use any of the removed or changed functions. > http://article.gmane.org/gmane.comp.graphics.png.devel/3283 > as I said: almost all new versions of libraries (those that developer knows what he/she is doing) maintain functions that are compatible with previous versions functions .. that's why gtk continue (right now) working on my box > It's much safer to just leave the libraries alone. agree >=C2=A0Just because you > upgraded libpng doesn't mean that your old gtk binary will stop working I disagree .. I have a program that depends on 'libpng.so.5' .. I tried to execute it after upgrade 'png' and it don't started becase the system lacks 'libpng.so.5' I solved the situation RECOMPILING the program .. doing that the program linked against NEW 'libpng.so.6' and when I tried to execute it once again it works fine > Anyway, the FreeBSD port maintainers usually bump the > revision of dependant ports when a major library like libpng gets upgrade= d, > to force everyone to upgrade anything that depends on it. > mmm .. I think it's not true because I maintain a port and i'm VERY VERY restricted to update the port because I depends on a mentor that will ONLY update the port in fbsd svn tree if I sent to him the tinderbox log of the sucessfully build of the port .. so I have not much patience to do all this things so I update the port and do ALL task including constructing the package into tinderbox ONLY when a new version of the program is available .. and I think that exists a lot of ports maintainers that are in same situation do you agree with me that it's difficult to a port maintainer to update his/her port because of this restriction???? could be a good idea to plan and implement a system to allow fbsd ports maintainers to maintain easyly the own ports via web or mail ONCE a fbsd mentor have uploaded his/her port to fbsd svn tree????????????? >> i think this is a VERY VERY strict rule because in linux programs load >> 'lib*.so' instead 'lib*.so.#' except if that program was linked to >> 'lib*.so.#' at compilation time > > no, the rule is the same in Linux. =C2=A0Programs load "lib*.so.#" there = also: > > (dan@linuxbox) ~># ldd /usr/bin/rrdtool > =C2=A0 =C2=A0 =C2=A0 =C2=A0linux-vdso.so.1 =3D> =C2=A0(0x00007fff4f9ff000= ) > =C2=A0 =C2=A0 =C2=A0 =C2=A0librrd.so.2 =3D> /usr/lib64/librrd.so.2 (0x000= 07fa047716000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libfreetype.so.6 =3D> /usr/lib64/libfreetype.s= o.6 (0x00007fa04759b000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libpng.so.3 =3D> /usr/lib64/libpng.so.3 (0x000= 07fa04745f000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libz.so.1 =3D> /lib64/libz.so.1 (0x00007fa0473= 4b000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libart_lgpl_2.so.2 =3D> /usr/lib64/libart_lgpl= _2.so.2 (0x00007fa047234000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libm.so.6 =3D> /lib64/libm.so.6 (0x00007fa0470= df000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.6 =3D> /lib64/libc.so.6 (0x00007fa046e= 9f000) > =C2=A0 =C2=A0 =C2=A0 =C2=A0/lib64/ld-linux-x86-64.so.2 (0x00007fa04785e00= 0) > > -- > =C2=A0 =C2=A0 =C2=A0 =C2=A0Dan Nelson > =C2=A0 =C2=A0 =C2=A0 =C2=A0dnelson@allantgroup.com