octave-maintainers
[Top][All Lists]
Advanced

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

Updating glpk binding to GLPK 4.15


From: Rafael Laboissiere
Subject: Updating glpk binding to GLPK 4.15
Date: Mon, 19 Feb 2007 02:49:09 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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.

-- 
Rafael

Attachment: __glpk__.cc-diffs
Description: Text document


reply via email to

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