Updating glpk binding to GLPK 4.15

[John W. Eaton]

On 19-Feb-2007, Rafael Laboissiere wrote:

| GLPK 4.15 has been released on February 18.  The code is essentially the
| same as in 4.14, the difference being that this new version has libtool
| support and can generate shared libraries.
| 
| Anyway, __glpk__.cc was already broken for 4.14, as it has already been
| posted in this mailing list ten days ago.  The reasons for the failure are:
| 
| 1) Neither lib_set_print_hook (or lib_print_hook) nor lib_set_fault_hook (or
|    lib_fault_hook) are part of the official API.
| 
| 2) The macro "insist" is not available anymore (it is defined in the header
|    file glplib.h, which is no more installed by GLPK in the standard place).
| 
| 3) The function lib_env_ptr is not part of the API anymore.  Besides, it
|    accesses the LIBENV structure (which is not part of the API neither).
|    Even worse, the code in __glpk__.cc tries to access the mem_tpeak member
|    of LIBENV, which is a structure, by casting it to a double, which is
|    impossible.
| 
| I discussed these issues with Andrew Makhorin, the author of GLPK, and he
| suggested the patch attached below, which I am currently applying to the
| Debian package.  Notice that this patch will not work for versions of GLPK
| prior to 4.14.  To limit Octave to this version or later, the test in
| configure.in should be changed to check only for _glp_lpx_simplex.
| 
| Andrew told me that he will implement a workaround to avoid the direct call
| to the _glp_lib_print_hook and _glp_lib_fault_hook functions, which are
| private but accessible from libglpk.so.  Also, notice that the value
| returned in EXTRA.mem is always zero.  I do not now whether it will be
| possible to access, through the public API, the amount of used memory in the
| future.

I only see 4.11 in Debian testing now, so please fix this patch so
that Octave can continue to use older versions of glpk.  If necessary,
we can check for the features in the configure script, but I think it
would be better if you can do it with preprocessor macro checks in the
__glpk__.cc file itself.

Thanks,

jwe