On Thu, Oct 17, 2013 at 10:12:47AM -0500, Bruce Dubbs wrote: > alex lupu wrote: > > Hi Bruce, > > > >>> ... > >>> 921939 2012-03-27 12:51 libjpeg.so.8.4.0 > >>> 425541 2013-09-30 12:05 libjpeg.so.8.0.2 > >>> 16 2013-09-30 12:05 libjpeg.so.8 -> libjpeg.so.8.4.0 > >>> 16 2013-09-30 12:05 libjpeg.so -> libjpeg.so.8.0.2 > > > >> ... > >> Note that only libjpeg.so -> libjpeg.so.8.0.2 is used for new builds and > >> libjpeg.so.8 points to libjpeg.so.8.4.0. I think there is a potential > >> problem there. > > > > Was this problem caused by me (by mistake, obviously) or is this the way > > libjpeg installs these days? > > I don't know. I only have > > /usr/lib/libjpeg.so -> libjpeg.so.8.0.2 > /usr/lib/libjpeg.so.8 -> libjpeg.so.8.0.2 > /usr/lib/libjpeg.so.8.0.2 > > right now. Those are from libjpeg-turbo-1.3.0. > > -- Bruce > Been here, and eventually found the problem. This is only an issue for people who install libjpeg-turbo on a system where libjpeg is already installed.
1. Turbo installs v8 jpeg as 8.0.2, but most people who had real jpegsrc.v8 used "newer" versions such as the 8.4.0 in this case. 2. ldconfig will remake the symlinks whenever it is run, and will point to the newest version (8.4.0 in this case). For me, this was an issue whenever I upgraded things on old (as in "built before I used jpeg-turbo") systems - firefox would break (ran, but not all jpegs, particularly thumbnails, were displayed. Now I've only got one or two such systems, and only firefox is likely to get updated on them. My firefox upgrade script now checks where libjpeg.so.8 points, and forcibly remakes the symlink to point to the lower number where necessary. People who built jpeg-turbo as v7 or v6 might also see a similar issue. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
