Re: [Help-glpk] Clean method for GLPK detection in autoconf script

[Andrew Makhorin]

Tuesday, April 24, 2007, 7:22:30 PM, you wrote:

> I upgraded from GLPK 4.13 to GLPK 4.15, and it caused trouble in one
> of my autotools'ed packages. The GLPK detection method I included in
> my configure.ac script was looking like the following :

> AC_CHECK_LIB([glpk], [glp_lpx_create_prob],
>      [AC_DEFINE([HAVE_LIBGLPK], [1],
>              [Defined if you have libglpk])
>       MODULES="${MODULES} glpk"
>      ])

> This way it detects a glp_lpx_create_prob function in an eventually
> existing libglpk library file. Indeed, exported GLPK function names
> have a "glp_" prefix before each function name.

> Since GLPK 4.15 the function prefix has changed, now it is "_glp_".
> Thus, my detection method doesn't work anymore, and if I change
> glp_lpx_create_prob to _glp_lpx_create_prob, my package won't detect
> earlier releases of GLPK.

> Hence my questions : why are the exported function names different
> than the documented ones, and why have they changed ?

They are changed in order to keep the namespace clean, i.e. all
external names visible to the linker are prefixed by '_glp_'. This
concerns all glpk routines, in particular, old api routines whose
names begin with 'lpx_'.

I understand that any changes in api are painful. However, it is
difficult to take into account all technical aspects that may appear
on using the package. Hope many of them will be resolved in 4.16.

> is there a clean and standard method for GLPK detection in
> configure.ac scripts ?

I am not sure about a standard method. Probably, to detect if glpk
is installed you could check if the header 'glpk.h' is available, i.e.
something like this:

AC_CHECK_HEADERS([glpk.h])
if test "$ac_cv_header_glpk_h" = yes; then
LIBS="-lglpk $LIBS"
else
AC_MSG_WARN([GLPK not installed.])
fi


Andrew Makhorin