Hi David, First of all -
> P.S. Two of the packages of mine which you mention -- imagemagick1-shlibs > and libdjvulibre15-shlibs -- are in fact old (perhaps obsolete) versions of > packages which exist in newer versions in fink. THERE IS ABSOLUTELY NO > REASON TO CHANGE OBSOLETE PACKAGES to use a different library. That's good. I agree with your last unnecessarily uppercase statement. I'll get the libraries that depended on these packages to bump to newer versions of those two libraries. Then, > The shared libraries of libjpeg and libjpeg8 have different names, and the > dynamic linker cannot possibly confuse them. There is a remote possibility > that some other library is confusing symbols between libjpeg and libjpeg8, > but my understanding is that whatever symbols are in common between the > two are identical. > > Fink's entire system was built on this important property of the OS X dynamic > linker: old versions of the library can stay around for things that need them, > even when newer versions of the library have been created. This works as > long as library maintainers follow the correct versioning rules, but -- as > indicated > above -- I've seen no evidence that the libjpeg/libjpeg8 transition violates > any versioning rules. We talked about this on IRC but I'll repeat here for the purpose of mailman archives and interested developers. The bug I've been seeing occurs in KDE/Qt applications, on various machines. I always see that the crash occured in jpeg_decompress or some other jpeg_ function. And always, when I look at loaded symbols, I saw both libjpeg.8.dylib and another libjpeg.something.dylib loaded. When I removed libjpeg-shlibs, only libjpeg.8.dylib was loaded and the crash did not occur. My conclusion was that somewhere, some KDE (or less likely Qt) library loads whatever libjpeg library it can find, probably without checking if one is already loaded, so it loads libjpeg.old.dylib. Then, some other part uses jpeg functions and gets the two mixed up - for example, it initialises the private jpeg struct from libjpeg.8, and then it feeds it to jpeg_decompress of the old library. > So, while it may be desirable to convert, there should be no urgency whatsover > about the conversion. > > I strongly encourage you to investigate the "crashes" you are reporting > further, to determine their true cause. What happens exactly I don't know. All I do know is: libjpeg-shlibs being installed makes kde applications crash on various machines. libjpeg-shlibs is old and obsoleted by libjpeg8-shlibs. 1+1=2: get rid of libjpeg-shlibs in favor of the new version. However, you have already fixed libtiff yourself, so I guess we both agree now that this is the right way to go. Thanks, Sjors ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
