--- Gio 26/3/09, Andrew Makhorin ha scritto: > Da: Andrew Makhorin > Oggetto: Re: [Help-glpk] autoreconf issue and octave > A: "Marco Atzeri" > Cc: help-glp , "xypron" > Data: Giovedì 26 marzo 2009, 15:16 > Hi Marco, > > Thank you for your efforts in maintaining a cygwin version > of glpk. > > Following your requirements I did the following: > > 1. I added AC_CONFIG_MACRO_DIR([m4]) to configure.ac and > ACLOCAL_AMFLAGS=-I m4 to makefile.am as > it is recommended by the > libtool developers. Thus, now libtool > macros are written to m4 > subdirectory. (Note, however, that > aclocal writes its macros in > aclocal.m4, not in m4/aclocal.m4; I think > this is normal.) > > 2. I added $(srcdir) to makefile.am's, so now glpk can be > built in > a directory other than its source > directory. > > > building the glpk package for cygwin I always had > problem > > with autoreconf as autoheader complains of missing > template for > > > HAVE_GMP, HAVE_ZLIB, HAVE_LTDL, HAVE_DLFCN, > ODBC_DLNAME], > > MYSQL_DLNAME. > > In glpk distribution config.h.in is written manually. Since > it is > *not* generated by autoheader, third argument (description) > in AC_DEFINE > is not needed as explained in: > http://www.gnu.org/software/hello/manual/autoconf/Defining-Symbols.html > > > The attached patch solve the issue and also allow me > > the building in a separate directory from src > directory. > > Done. See above. > > > The last portion is probably eccessive > > ************************************************** > > > lib_LTLIBRARIES = libglpk.la > > > -libglpk_la_LDFLAGS = -version-info 21:0:21 \ > > --export-symbols-regex '^(glp_|_glp_lpx_).*' > > +libglpk_la_LDFLAGS = -version-info 21:0:21 > > > libglpk_la_SOURCES = \ > > glpapi01.c > > ************************************************** > > I was asked by the GNU/Linux maintainer not to export > non-API symbols. > > > but the regex is cutting two functions > > currently used by octave (www.octave.org) > > > void _glp_lib_print_hook (int (*func)(void *info, char > *buf), void *info); > > void _glp_lib_fault_hook (int (*func)(void *info, char > *buf), void *info); > > > is it possible to have these two functions exported > > as in the past ? > > In principle, yes. However, I think it is better to make > changes in > the octave/glpk interface module itself.
I will give a look, but I saw a lot of surprise when glpk stopped to have a working interface for octave when linking dynamic libraries. These are the only functions called by octave __glp_lib_fault_hook __glp_lib_print_hook so we need to re-write completely the interface...? By the way, which is the difference between : __glp_lib_term_hook (not exported) _glp_term_hook (exported) > > Could you have a closer look at glpk distribution before I > will make > a new release? If so, I could post you the glpk pre-release > tarball via > e-mail (about 2Mb gzipped). > > > Thanks, > > Andrew Makhorin > send me Marco _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
