From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 14 17:48:55 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 027891065672 for ; Wed, 14 Apr 2010 17:48:55 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id BBDD28FC0A for ; Wed, 14 Apr 2010 17:48:54 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o3EHmr2G024660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Apr 2010 12:48:53 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o3EHmrTb017313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Apr 2010 12:48:53 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o3EHmrYS017312; Wed, 14 Apr 2010 12:48:53 -0500 (CDT) (envelope-from dan) Date: Wed, 14 Apr 2010 12:48:53 -0500 From: Dan Nelson To: Leinier Cruz Salfran Message-ID: <20100414174853.GC43908@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 14 Apr 2010 12:48:53 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-hackers@freebsd.org 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 17:48:55 -0000 In the last episode (Apr 14), Leinier Cruz Salfran said: > i want to know if there is a possibility to avoid current strict libraries > linking .. i will explain myself > > for example .. i have installed 'gtk' (2.18) that depends on library > 'libpng.so.5' (png) .. and i will upgrade 'png' port to a superior > version that install the library 'libpng.so.6' BUUUTTTT 'gtk' will not be > upgraded, so it will still depending on 'libpng.so.5' .. so here is my > question: there is a way to avoid this?????? i means that 'gtk' load > '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 its argument list changing, or a structure changing size. Symlinking one version onto another version might work, but only if the application doesn't use any of the removed or changed functions. http://article.gmane.org/gmane.comp.graphics.png.devel/3283 It's much safer to just leave the libraries alone. Just because you upgraded libpng doesn't mean that your old gtk binary will stop working (assuming you are using "portupgrade" or "portmaster -w" which preserves old libraries of course). Anyway, the FreeBSD port maintainers usually bump the revision of dependant ports when a major library like libpng gets upgraded, to force everyone to upgrade anything that depends on it. > 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. Programs load "lib*.so.#" there also: (dan@linuxbox) ~># ldd /usr/bin/rrdtool linux-vdso.so.1 => (0x00007fff4f9ff000) librrd.so.2 => /usr/lib64/librrd.so.2 (0x00007fa047716000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa04759b000) libpng.so.3 => /usr/lib64/libpng.so.3 (0x00007fa04745f000) libz.so.1 => /lib64/libz.so.1 (0x00007fa04734b000) libart_lgpl_2.so.2 => /usr/lib64/libart_lgpl_2.so.2 (0x00007fa047234000) libm.so.6 => /lib64/libm.so.6 (0x00007fa0470df000) libc.so.6 => /lib64/libc.so.6 (0x00007fa046e9f000) /lib64/ld-linux-x86-64.so.2 (0x00007fa04785e000) -- Dan Nelson dnelson@allantgroup.com