Re: [Help-glpk] autoreconf issue and octave

[Marco Atzeri]

--- 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