Just a question here, I've noticed that the recommended fix for GLPK includes: #ifdef GLPK_PRE_4_15 which seems to indicate to me that it will still be a problem if someone happens to be running 4.14 (as the bindings changed from 4.13 to 4.14 and apparently the EXTRA.mem changed from 4.14 to 4.15. So technically, it looks like octave with the revisions will work with any version of glpk _except_ 4.14. Is this correct? (If you read closely, the change had only been tested with 4.11 and 4.15.) - M. On Feb 27, 2007, at 4:01 PM, macports-users- request@lists.macosforge.org wrote:
I also made the patches necessary to fix glpk, as per the discussion with Andrew Makhorin here:
http://www.nabble.com/Updating-glpk-binding-to-GLPK-4.15- t3250570.html
On Feb 27, 2007, at 20:49 , M. White wrote:
Just a question here, I've noticed that the recommended fix for GLPK includes:
#ifdef GLPK_PRE_4_15
which seems to indicate to me that it will still be a problem if someone happens to be running 4.14 (as the bindings changed from 4.13 to 4.14 and apparently the EXTRA.mem changed from 4.14 to 4.15. So technically, it looks like octave with the revisions will work with any version of glpk _except_ 4.14. Is this correct? (If you read closely, the change had only been tested with 4.11 and 4.15.)
I believe the glpk patch for the octave port modifies __glpk__.cc directly to declare and call functions that still exist in the library but are no longer declared (i.e. exposed) in the gplk header file. It does not setup or use the GLPK_PRE_4_15 macro. I'm not sure whether this results in a .cc file that is compatible with version 4.14, but since the current glpk port is revision 4.15 does anyone need 4.14 compatibility? Dave
participants (2)
-
David MacMahon
-
M. White