[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-glpk] autoreconf issue and octave
From: |
Andrew Makhorin |
Subject: |
Re: [Help-glpk] autoreconf issue and octave |
Date: |
Thu, 26 Mar 2009 17:16:12 +0300 |
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.
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