Jack Howarth wrote: > ...I assume it is safe to bump the compatibility level in the > gmp and ppl info files. Unless I am mistaken this issue is also > exactly why the fftw3 package was left at 3.1.2 for so long > since the current 3.2.1 package bumps the compatibility > level but not the soversion. My previous understanding was > that the compatibility level should always be one more than > the major soversion. However it would appear that this doesn't > have to be the case and that the relationship between the two > is more flexible than that. If this is really the case, this > information should be clearly stated in the shared libraries > section of the fink packaging wiki.
Jack, I don't know what the issue is with fftw3, but here is some quick info on install_names (sonames) and compatibility versions. For libtool built libraries the upstream developer will usually specify CURRENT:REVISION:AGE, and the library name on darwin is calculated as: libname.(CURRENT -AGE).dylib The compatibility version is calculated as: CURRENT + 1 I dislike that +1, but it can not be removed now without breaking everything. This means that for your ppl example: # 0.10 7:0:0 # 0.10.1 8:0:1 version 0.10 of ppl had: libppl.7.dylib compatibility version 8.0.0 version 0.10.1 has: libppl.7.dylib compatibility version 9.0.0 So anything that uses libppl that was built using version 0.10 will continue to run fine using 0.10.1. *However* anything that was built with version 0.10.1 will *not* work if dyld sees that 0.10 is installed. This is fine if you are building your own stuff, as it is unlikely that you will ever downgrade your library, for a package management system that distributes binaries, it is quite important though. The package maintainer of a package that uses, in this case, ppl, must ensure that, when the user installs a gcc that was built with a newer ppl, the user also gets a newer ppl, if the dependencies only require ppl >= 0.10, then the user could try to run gcc and get a "crash" because dyld will refuse to load the older ppl. The shlibs field etc. was invented for a feature that has been on the list of things todo for fink for a very long time - automatically set depends in the binary package for the shared libraries that are actually used at link time. I think Justin worked on this for a while, but it was years ago, and I don't remember how far he got. Does this make it any clearer? Please feel free to add anything you find useful in this mail to the wiki. Peter -- Peter O'Gorman http://pogma.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
