> 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. _______________________________________________ Bug-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-glpk
