On Feb 28, 2007, at 7:32 AM, macports-users- request@lists.macosforge.org wrote:
From: David MacMahon <davidm@astro.berkeley.edu> Subject: Re: glpk patch for octave To: macports-users@lists.macosforge.org Message-ID: <00209460-3FC5-4F61-A488-314E4183D90A@astro.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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
Ah, if that is the case, then the patch should work for 4.14 (but not for earlier than 4.14). The only functionality that would be lost is the EXTRA.mem call (which if __glpk__.cc was patched the way I expect it was, it will now have a line something like *mem = 0;) and that is not too much of a problem, as in 4.15 that functionality is lost anyway. I was not sure if you were trying to patch keeping in mind backwards compatibility or not. - M.