[Bug-glpk] Re: table compatibility of GLPK 4.32

2008-10-22 Thread Andrew Makhorin 
  I am working on GLPK 4.32 and ran in to the following error while
  trying to use the table command. Is there a known bug in the version
  that handles tables ? Many thanks || Sincerely || Rajesh

 --
 [EMAIL PROTECTED]:~/glpk-4.32/examples/csv$ glpsol  -m transp_csv.mod
 Reading model section from transp_csv.mod...
 transp_csv.mod:38: colon missing where expected
 Context:  , j in J } ; param e { l in L } ; param f ; table tab_plant
 Model processing error
 -

Hmm... It works fine for me:

Reading model section from transp_csv.mod...
70 lines were read
Reading tab_plant...
Reading tab_market...
Reading tab_distance...
Reading tab_parameter...
Generating cost...
Generating supply...
Generating demand...
Model has been successfully generated
glp_simplex: original LP has 6 rows, 6 columns, 18 non-zeros
glp_simplex: presolved LP has 5 rows, 6 columns, 12 non-zeros
Scaling...
 A: min|aij| =  1.000e+00  max|aij| =  1.000e+00  ratio =  1.000e+00
Problem data seem to be well scaled
Crashing...
Size of triangular part = 5
  0: obj =   0.0e+00  infeas =  9.000e+02 (0)
* 4: obj =   1.56375e+02  infeas =  0.000e+00 (0)
* 5: obj =   1.53675e+02  infeas =  0.000e+00 (0)
OPTIMAL SOLUTION FOUND
Time used:   0.0 secs
Memory used: 0.1 Mb (138775 bytes)
Writing tab_result...
Model has been successfully processed

Looks like the 'table' keyword is not recognized. From where did you
download the distribution tarball? Which options did you pass to the
configure script on building the package? Does glpsol successfully
process other example models?



___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk

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

2008-10-22 Thread 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.



___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk