octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GLPK API change


From: John W. Eaton
Subject: GLPK API change
Date: Thu, 8 Feb 2007 13:57:48 -0500

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.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]