Re: [Bug-glpk] glpk 4.32 on Mac OS X

[Andrew Makhorin]

> I have run into a problem building octave 3.0.3 against glpk
> version 4.32. When I investigated the issue, I found that the build
> works correctly for version 4.31, but not 4.32. The offending
> symbols are

>  For version 4.32:

> nm /usr/local/lib/libglpk.0.17.0.dylib | grep 'lib_[a-z]*_hook'

>          u __glp_lib_term_hook
> 0002e856 t __glp_lib_fault_hook
> 0002ea9b t __glp_lib_print_hook
> 0002ea65 t __glp_lib_term_hook

> whereas I get

> nm /usr/local/lib/libglpk.0.16.0.dylib | grep 'lib_[a-z]*_hook'
>          U __glp_lib_term_hook
> 00031623 T __glp_lib_fault_hook
> 00031868 T __glp_lib_print_hook
> 00031832 T __glp_lib_term_hook

> for version 4.31

> The lower-case t means they are file-scope symbols.  So why are they
> no longer exported?  Is that intentional, or a bug in 4.32?

> This seems not to be a problem for Debian Experimental and SuSe
> 10.3 as they cleanly build octave 3.0.3 with glpk 4.32.

Thank you for the bug report.

In 4.32 only API routines are exported while __glp_lib_term_hook,
etc. are non-api routines, which unfortunately are still used in the
octave interface module.

To fix the problem you may try to replace:

libglpk_la_LDFLAGS = -version-info 17:0:17 \
-export-symbols-regex '^(glp_|_glp_lpx_).*'

in file src/Makefile.am with:

libglpk_la_LDFLAGS = -version-info 17:0:17

(that allows exporting all symbols) and then rebuild the package.