[Fink-devel] gmp-4.3.0-1000
I've built and tested new gmp-4.3.0-1000 packaging on both a G4 and G5. In both cases the make test completes without errors. I did notice that the compatibility level has been bumped... Error: Shlibs field says compatibility version for /sw/lib/libgmp.3.dylib is 8.0.0, but it is actually 9.0.0. From what Peter O'Gorman said about a similar situation in the new ppl-0.10.1 release... http://gcc.gnu.org/ml/gcc/2009-04/msg00444.html ...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 -- 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
[Fink-devel] compatibiltiy versions (was: Re: gmp-4.3.0-1000)
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.107: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
Re: [Fink-devel] compatibiltiy versions (was: Re: gmp-4.3.0-1000)
On Wed, Apr 15, 2009 at 10:34:56AM -0500, Peter O'Gorman wrote: 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.107: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 Peter, So it is completely legal in fink to go ahead and upgrade a package (gmp-4.3.0, ppl-0.10.1 and fftw3-2.3.1) which has bumped the compatibility level but not the major soversion number as long as you insure that all packages that BuildDepend/Depend against these have been updated to require the newer version? My recollection is that there was a concern that this was a mistake upstream and that the major soversion should have been bumped so that the fftw3 maintainer never wanted to update to the newer version for that reason. Regarding the additional functionality in fink, are you referring to the missing library dependencies in dpkg (where a deb knows explicitly all of the specific libraries that its shared libraries and executables are linked against) such that attempting to remove a package that has shared libraries that some other packages files need will flag an error (no matter if the dependencies aren't stated in the info file)? My understanding was that was extremely difficult to implement on darwin because of the explicit path information (rpath?) used in linking. Jack -- 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
Re: [Fink-devel] compatibiltiy versions (was: Re: gmp-4.3.0-1000)
On Apr 15, 2009, at 8:49 AM, Jack Howarth wrote: So it is completely legal in fink to go ahead and upgrade a package (gmp-4.3.0, ppl-0.10.1 and fftw3-2.3.1) which has bumped the compatibility level but not the major soversion number Yes, completely legal. as long as you insure that all packages that BuildDepend/Depend against these have been updated to require the newer version? That is not necessary. If the upstream maintainers are doing things correctly, the new version of the library will continue to work with old packages. My recollection is that there was a concern that this was a mistake upstream Sometimes the upstream packagers make mistakes and should have bumped the major soversion when they didn't. But unless you have a reason to believe that is the case, you should assume that the compatibility is correctly measured by compatibility_version. Regarding the additional functionality in fink, are you referring to the missing library dependencies in dpkg (where a deb knows explicitly all of the specific libraries that its shared libraries and executables are linked against) such that attempting to remove a package that has shared libraries that some other packages files need will flag an error (no matter if the dependencies aren't stated in the info file)? My understanding was that was extremely difficult to implement on darwin because of the explicit path information (rpath?) used in linking. Not extremely difficult, just different than Debian. We have a way to do it, but nobody found the time to fully implement it. -- Dave -- 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
[Fink-devel] Does your package do mysql15 | mysql15-ssl ? If so, it's probably broken. :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 They are not binary compatible with each other, you can't build against one and have it work on the other: diff -Nurd /tmp/nossl.txt /tmp/ssl.txt | c++filt | grep '^+' | wc -l 2029 If you were to build foo against mysql-ssl15-shlibs, it will not run if you switch it out with mysql15-shlibs. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ5m1SUu+jZtP2Zf4RArYPAJ9MikF6mNJyVmGzxOzIlHc6+PAuVACfXb0C alFOyNo/cAW3u6Fzu2DahWc= =XhQL -END PGP SIGNATURE- -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
