Date: Wed, 14 Apr 2010 14:18:40 -0400 From: Leinier Cruz Salfran <salfrancl.listas@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: there is a way to avoid strict libraries linking? Message-ID: <x2ua2585ef1004141118m80991b08of6f7ac2478c0009e@mail.gmail.com> In-Reply-To: <20100414174853.GC43908@dan.emsphone.com> References: <n2ya2585ef1004140923s2acb8b2ctf7c9b449cb66f208@mail.gmail.com> <20100414174853.GC43908@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson <dnelson@allantgroup.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x2ua2585ef1004141118m80991b08of6f7ac2478c0009e>