On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson <dnel...@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 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 >
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 > Just 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 upgraded, > 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. Programs load "lib*.so.#" there also: > > (d...@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 > dnel...@allantgroup.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
