Re: GLPK API change

[Michael Goffioul]

John W. Eaton a écrit :
> On  8-Feb-2007, address@hidden wrote:
>
> | Hi,
> | 
> | I wanted to update the GLPK library to the latest version (4.14), but it
> | appears that the API has changed, leading to compilation errors in
> | __glpk__.cc. See the following (ugly) patch to see what changes are
> | required.
> | 
> | The previous version I was using is 4.9. So the question is: should octave
> | require the latest version of GLPK (and __glpk__.cc should be changed
> | accordingly, not with my ugly patch), or should it support both API?
> | 
> | Note also that the test in the configure script will fail because it looks for
> | the symbol glp_lpx_simplex, while now all symbols are prepended with
> | an underscore.
> | 
> | Michael.
> | 
> | Index: src/DLD-FUNCTIONS/__glpk__.cc
> | ===================================================================
> | RCS file: /cvs/octave/src/DLD-FUNCTIONS/__glpk__.cc,v
> | retrieving revision 1.17
> | diff -c -p -r1.17 __glpk__.cc
> | *** src/DLD-FUNCTIONS/__glpk__.cc       6 Jul 2006 22:34:55 -0000       1.17
> | --- src/DLD-FUNCTIONS/__glpk__.cc       8 Feb 2007 13:40:05 -0000
> | *************** Software Foundation, Inc., 51 Franklin S
> | *** 40,45 ****
> | --- 40,54 ----
> |   
> |   extern \"C\" {
> |   #include <glpk.h>
> | + #ifndef _GLPLIB_H
> | + #include <glplib.h>
> | + #endif
> | + #ifndef lib_set_fault_hook
> | + #define lib_set_fault_hook lib_fault_hook
> | + #endif
> | + #ifndef lib_set_print_hook
> | + #define lib_set_print_hook lib_print_hook
> | + #endif
> |   }
>
> OK, that is simple enough.
>
> |   #define NIntP 17
> | *************** glpk (int sense, int n, int m, double *c
> | *** 342,348 ****
> | --- 351,361 ----
> |         }
> |   
> |         *time = (clock () - t_start) / CLOCKS_PER_SEC;
> | + #ifdef ulong_t
> | +       *mem = *(unsigned long long*)&(lib_env_ptr () -> mem_tpeak);
> | + #else
> |         *mem = (lib_env_ptr () -> mem_tpeak);
> | + #endif
>
> I'm not so sure about this cast.  Why unsigned long long if mem_tpeak
> is unsigned long?  Do all systems have long long?  Also, *mem is a
> double, so is this really the right thing to do?  And in any case,
> please use C++ style casts as they are easier to find.
>   

As I said, this is just un ungly patch, not intended to be applied. This 
is just to illustrate
where things changed. In this case, what has changed is the type of 
mem_tpeak, which
switched from int to ulong_t. This ulong_t type is defined as:

typedef struct { unsigned int low, high; } ulong_t;

This type cannot be casted simply to a double. However, this type has 
the same layout
as unsigned long long on my x86 computer. So the cast was the fastest 
and also most
non-portable solution I tried to check it worked on my setup. Something more
appropriate has to be used.

Michael.