Re: [Fink-devel] Require new libversioned packages for those using Frameworks?
Alexander K. Hansen wrote: Alexander K. Hansen wrote: Benjamin Reed wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? Sounds like the path of a public .dylib changed, therefore the package name needs to change, which would be a clear example of how to not-follow Shared Library Policy (and a good data point for why that policy is a Good Thing). What's install_name of the .dylib file, and does validator in CVS HEAD not whine about a .dylib that isn't declared in a Shlibs field? Looks like they misused frameworks, and should have /Versions/2 be a symlink to 2.5, and the install_names should be modified to use /Versions/2.5/Resources/... (if they are indeed forward-compatible) If they are truly different, and incompatible, they should have a new - -shlibs package. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ - They have Versions/2.5 as a symlink to /Versions/2.5.1. The install_name is /sw/Library/Frameworks/R.framework/Versions/2.5/Resources/lib/libR.dylib I made a symlink .../Versions/2.4 - .../Versions/2.5 and my old labplot was happy to use the new r-base, so if the libR.dylib are incompatible, it's more subtle. I'm updating the r-base package to 2.6.0 now - so what is the recommended way to handle Framework versioning? What I have now is [EMAIL PROTECTED]:/sw/fink/dists/local/main/finkinfo] ls -l /sw/Library/Frameworks/R.framework/Versions total 8 drwxrwxr-x 6 root admin 204 Oct 6 07:41 2.6 lrwxr-xr-x 1 root admin 47 Oct 6 07:41 2.6.0 - /sw/Library/Frameworks/R.framework/Versions/2.6 lrwxr-xr-x 1 root admin 3 Oct 6 07:41 Current - 2.6 [EMAIL PROTECTED]:/sw/fink/dists/local/main/finkinfo] ls -l /sw/Library/Frameworks/R.framework/Versions/2.6 total 8 lrwxr-xr-x 1 root admin 17 Oct 6 07:41 Headers - Resources/include drwxrwxr-x 51 root admin 1734 Oct 6 07:41 PrivateHeaders lrwxr-xr-x 1 root admin 24 Oct 6 07:41 R - Resources/lib/libR.dylib drwxrwxr-x 17 root admin 578 Oct 6 07:41 Resources -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Require new libversioned packages for those using Frameworks?
(relevant maintainer cc'ed) I built labplot against a 2.4.x version of r-base. I hadn't run it in a while, and sometime during that interval r-base got updated to 2.5.x . Lo and behold, when I tried to run labplot today, I got: $ labplot dyld: Library not loaded: /sw/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libR.dylib Referenced from: /sw/bin/labplot Reason: image not found Trace/BPT trap because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? -- Alexander K. Hansen Fink User Liaison/Documenter akh AT finkproject DOT org - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Require new libversioned packages for those using Frameworks?
On Wed, Oct 03, 2007 at 11:02:00AM -0400, Alexander K. Hansen wrote: I built labplot against a 2.4.x version of r-base. I hadn't run it in a while, and sometime during that interval r-base got updated to 2.5.x . Lo and behold, when I tried to run labplot today, I got: $ labplot dyld: Library not loaded: /sw/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libR.dylib Referenced from: /sw/bin/labplot Reason: image not found Trace/BPT trap because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? Sounds like the path of a public .dylib changed, therefore the package name needs to change, which would be a clear example of how to not-follow Shared Library Policy (and a good data point for why that policy is a Good Thing). What's install_name of the .dylib file, and does validator in CVS HEAD not whine about a .dylib that isn't declared in a Shlibs field? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Require new libversioned packages for those using Frameworks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? Sounds like the path of a public .dylib changed, therefore the package name needs to change, which would be a clear example of how to not-follow Shared Library Policy (and a good data point for why that policy is a Good Thing). What's install_name of the .dylib file, and does validator in CVS HEAD not whine about a .dylib that isn't declared in a Shlibs field? Looks like they misused frameworks, and should have /Versions/2 be a symlink to 2.5, and the install_names should be modified to use /Versions/2.5/Resources/... (if they are indeed forward-compatible) If they are truly different, and incompatible, they should have a new - -shlibs package. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA73iUu+jZtP2Zf4RAqcpAJ9ZWSycWj49OdoM2HZbpgK/cxIeLACggEuO dujrrYGAbR4rdIh8XA5KsYg= =GALV -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Require new libversioned packages for those using Frameworks?
Benjamin Reed wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? Sounds like the path of a public .dylib changed, therefore the package name needs to change, which would be a clear example of how to not-follow Shared Library Policy (and a good data point for why that policy is a Good Thing). What's install_name of the .dylib file, and does validator in CVS HEAD not whine about a .dylib that isn't declared in a Shlibs field? Looks like they misused frameworks, and should have /Versions/2 be a symlink to 2.5, and the install_names should be modified to use /Versions/2.5/Resources/... (if they are indeed forward-compatible) If they are truly different, and incompatible, they should have a new - -shlibs package. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ - They have Versions/2.5 as a symlink to /Versions/2.5.1. The install_name is /sw/Library/Frameworks/R.framework/Versions/2.5/Resources/lib/libR.dylib I -- Alexander K. Hansen Fink User Liaison/Documenter akh AT finkproject DOT org - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Require new libversioned packages for those using Frameworks?
Alexander K. Hansen wrote: Benjamin Reed wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Macks wrote: because libR.dylib is now in .../Versions/2.5/Resouces/lib/libR.dylib . Since the Framework build for the package installs into a libversioned directory already, it seems like the 2.4 library could have been kept around and the 2.5 update could have been a _new_ package (though this probably would entail additional Splitoffs). Thoughts? Sounds like the path of a public .dylib changed, therefore the package name needs to change, which would be a clear example of how to not-follow Shared Library Policy (and a good data point for why that policy is a Good Thing). What's install_name of the .dylib file, and does validator in CVS HEAD not whine about a .dylib that isn't declared in a Shlibs field? Looks like they misused frameworks, and should have /Versions/2 be a symlink to 2.5, and the install_names should be modified to use /Versions/2.5/Resources/... (if they are indeed forward-compatible) If they are truly different, and incompatible, they should have a new - -shlibs package. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ - They have Versions/2.5 as a symlink to /Versions/2.5.1. The install_name is /sw/Library/Frameworks/R.framework/Versions/2.5/Resources/lib/libR.dylib I made a symlink .../Versions/2.4 - .../Versions/2.5 and my old labplot was happy to use the new r-base, so if the libR.dylib are incompatible, it's more subtle. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
