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.