#20710 closed enhancement (fixed)
upgrade glpk to 4.60
Reported by:  François Bissey  Owned by:  

Priority:  major  Milestone:  sage7.5 
Component:  packages: standard  Keywords:  
Cc:  JeanPierre Flori, Erik Bray, Sebastien Gouezel, François Bissey  Merged in:  
Authors:  François Bissey  Reviewers:  Matthias Koeppe, Jeroen Demeyer 
Report Upstream:  N/A  Work issues:  
Branch:  fd7afa8 (Commits, GitHub, GitLab)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
I suggest to upgrade glpk
to the latest available version (4.60 at the time of writing). The current version has been superseded in Gentoo and the formatting of the output has changed.
Here are the tasks for this upgrade:
 use
spkgsrc
instead of patchingconfigure
directly
 some part of
have_error.patch
is now upstream, but not every piece of that patch was accepted
 clean up
SPKG.txt
and other files so they are reflecting the current reality more closely without obsolete historical comments
Tarball: http://www.lmona.de/files/sage/glpk4.60.tar.bz2 (generated with spkgsrc
)
Change History (72)
comment:1 Changed 6 years ago by
Authors:  → François Bissey 

Branch:  → u/fbissey/glpk_4.60 
Cc:  JeanPierre Flori added 
Commit:  → 79883a7750ec829abc0c41a6747c919e7e54db09 
comment:2 Changed 6 years ago by
comment:3 followups: 4 5 15 Changed 6 years ago by
I had been using glpk4.57
for a while (before moving to 4.60 in my private overlay before starting this ticket) and I had only one doctest failure (version reported is different and cannot just be ellipsed away because that doctest already uses tolerance) for a long time  until some recent MIP work which introduced new doctests. The failures are in verbosity and nothing about error reporting.
But to be sure do we already have a doctest for the functionality and if not, do you have a test case?
comment:4 Changed 6 years ago by
Replying to fbissey:
But to be sure do we already have a doctest for the functionality and if not, do you have a test case?
It has to do with error handling, which should be doctested. But I will check...
comment:5 followup: 6 Changed 6 years ago by
Replying to fbissey:
version reported is different and cannot just be ellipsed away because that doctest already uses tolerance
Well, 4.57
matches 4.55
with abs tol 0.02
:)
comment:6 Changed 6 years ago by
comment:7 Changed 6 years ago by
Commit:  79883a7750ec829abc0c41a6747c919e7e54db09 → b3efcbc8d4f8648d69563763a1f5b67db206457f 

comment:8 followup: 25 Changed 6 years ago by
Besides the error reporting there is one last doctest that require particular attention, possibly from a specialist
sage t long src/sage/numerical/backends/glpk_backend.pyx ********************************************************************** File "src/sage/numerical/backends/glpk_backend.pyx", line 1000, in sage.numerical.backends.glpk_backend.GLPKBackend.solve Failed example: p.solve() # rel tol 1 Exception raised: Traceback (most recent call last): File "/home/fbissey/sandbox/gitfork/sage/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 498, in _run self.compile_and_execute(example, compiler, test.globs) File "/home/fbissey/sandbox/gitfork/sage/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 861, in compile_and_execute exec(compiled, globs) File "<doctest sage.numerical.backends.glpk_backend.GLPKBackend.solve[74]>", line 1, in <module> p.solve() # rel tol 1 File "sage/numerical/mip.pyx", line 2197, in sage.numerical.mip.MixedIntegerLinearProgram.solve (/home/fbissey/sandbox/gitfork/sage/src/build/cythonized/sage/numerical/mip.c:15434) self._backend.solve() File "sage/numerical/backends/glpk_backend.pyx", line 1040, in sage.numerical.backends.glpk_backend.GLPKBackend.solve (/home/fbissey/sandbox/gitfork/sage/src/build/cythonized/sage/numerical/backends/glpk_backend.cpp:8609) MIPSolverException: GLPK: The time limit has been exceeded **********************************************************************
Also does that tell us something about error reporting as you intended it Jeroen?
comment:11 Changed 6 years ago by
(Are you using the upstream tarball or some kind of repackaged tarball?)
comment:13 Changed 6 years ago by
Description:  modified (diff) 

comment:14 Changed 6 years ago by
Dependencies:  → #20832 

comment:15 Changed 6 years ago by
comment:16 Changed 6 years ago by
Description:  modified (diff) 

You still need this piece of have_error.patch
(upstream explicitly rejected this):

src/env/error.c
diff ru glpk4.55/src/env/error.c glpk4.55patched//src/env/error.c
old new 47 47 va_end(arg); 48 48 xprintf("Error detected in file %s at line %d\n", 49 49 env>err_file, env>err_line); 50 env>err_file = NULL; 50 51 if (env>err_hook != NULL) 51 52 env>err_hook(env>err_info); 52 53 abort();
comment:17 followup: 18 Changed 6 years ago by
OK, can you enlighten me on why you think it is needed and why it was rejected?
comment:18 Changed 6 years ago by
The default behaviour for GLPK when encountering an error is to print an error message and then abort()
. This printing of the error message is done the same way as the usual printing of messages, for example with verbose output. The printing can be customized with a hook function.
GLPK also has an error hook, which is called after printing the error message. It can be used to do something else besides abort()
. In the case of Sage, this does a longjmp()
through the sig_on()
mechanism, raising a Python exception.
In Sage, we want the usual messages to appear normally, but we want to intercept the error messages and convert them to a Python exception. For this to work, we need a way to detect whether we are handling an error or not. I added a patch to GLPK to support this. It allows to checking whether env>err_file
is NULL
or not. This env>err_file
is set to some nonNULL value when entering the error handler and is set back to NULL after printing the error message, before the error hook.
The part which upstream did not accept was the setting back of env>err_file
to NULL because they don't want to officially support error recovery. In upstream's view, once GLPK has encountered an error, it is in an invalid state and there is no way to recover.
comment:19 Changed 6 years ago by
Grumble.... At least that's a very small patch. Will add it here in the morning.
comment:20 Changed 6 years ago by
Commit:  b3efcbc8d4f8648d69563763a1f5b67db206457f → dfa1ca62fc17ee47212255dfeb615267db959268 

comment:21 Changed 6 years ago by
OK delivered early. Now if we could have some comments from @jpflori about the cygwin bits we could put that to review.
comment:22 Changed 6 years ago by
Cc:  Erik Bray Sebastien Gouezel added 

ccing @embray and @gouezel as they might also have some thoughts about the cygwin portion.
comment:23 Changed 6 years ago by
And I forgot there is a failing doctest that needs to be looked at by a specialist at comment:8 but I believe we already have someone copied. So this is to bring it back in focus.
comment:24 Changed 6 years ago by
Description:  modified (diff) 

comment:25 Changed 6 years ago by
Replying to fbissey:
Besides the error reporting there is one last doctest that require particular attention, possibly from a specialist
sage t long src/sage/numerical/backends/glpk_backend.pyx ********************************************************************** File "src/sage/numerical/backends/glpk_backend.pyx", line 1000, in sage.numerical.backends.glpk_backend.GLPKBackend.solve Failed example: p.solve() # rel tol 1 Exception raised: Traceback (most recent call last): File "/home/fbissey/sandbox/gitfork/sage/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 498, in _run self.compile_and_execute(example, compiler, test.globs) File "/home/fbissey/sandbox/gitfork/sage/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 861, in compile_and_execute exec(compiled, globs) File "<doctest sage.numerical.backends.glpk_backend.GLPKBackend.solve[74]>", line 1, in <module> p.solve() # rel tol 1 File "sage/numerical/mip.pyx", line 2197, in sage.numerical.mip.MixedIntegerLinearProgram.solve (/home/fbissey/sandbox/gitfork/sage/src/build/cythonized/sage/numerical/mip.c:15434) self._backend.solve() File "sage/numerical/backends/glpk_backend.pyx", line 1040, in sage.numerical.backends.glpk_backend.GLPKBackend.solve (/home/fbissey/sandbox/gitfork/sage/src/build/cythonized/sage/numerical/backends/glpk_backend.cpp:8609) MIPSolverException: GLPK: The time limit has been exceeded **********************************************************************
This test tries to verify that no exception is raised when the optimization process is terminated early because of a set time limit. However, this is not actually true; no exception is raised only when GLPK has a feasible solution available when the time limit expires. Here (in version 4.60) it does not have a feasible solution available. I have not checked the details. On my machine, increasing the time limit to 0.1 fixes this test. Needless to say, this is of course a brittle test.
comment:26 Changed 6 years ago by
I should add that if one increases the time limit, one should probably increase "rel tol 1" to "rel tol 100", because it might find a better solution than 1 on a fast machine (or in a newer GLPK version).
comment:27 followup: 28 Changed 6 years ago by
Cc:  François Bissey added 

Funky the last email I received from this ticket is when Jeroen changed the description :(  Adding myself as cc to avoid problems.
Unless someone wants to write a new test I will make the changes suggested by Matthias to the failing doctest.
comment:28 Changed 6 years ago by
Replying to fbissey:
Unless someone wants to write a new test I will make the changes suggested by Matthias to the failing doctest.
Go ahead. There's no fundamentally better way to write a new test for this "feature" of the interface.
comment:29 Changed 6 years ago by
I had to raise the time limit to 1.0, 0.1 was not enough. My machine is not especially slow so I think it may fail on other machines even with 1.0
. I am thinking of raising it higher.
comment:30 Changed 6 years ago by
Commit:  dfa1ca62fc17ee47212255dfeb615267db959268 → c027aba847298d0adc61cfc8d85a421a1df1f5b6 

comment:31 Changed 6 years ago by
I get this (on Mac OS X):
File "src/sage/numerical/mip.pyx", line 2477, in sage.numerical.mip.MixedIntegerLinearProgram.number_of_variables.get_backend Failed example: p.solve() # rel tol 1e5 Expected: GLPK Simplex Optimizer, v4.60 2 rows, 2 columns, 4 nonzeros * 0: obj = 7.000000000e+00 infeas = 0.000e+00 (0) * 2: obj = 9.400000000e+00 infeas = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND 9.4 Got: GLPK Simplex Optimizer, v4.60 2 rows, 2 columns, 4 nonzeros * 0: obj = 7.000000000e+00 inf = 0.000e+00 (2) * 2: obj = 9.400000000e+00 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND 9.399999999999999 Tolerance exceeded in 1 of 13: 0 vs 2, tolerance inf > 1e05
Should this ticket be in needs_review
?)
comment:32 Changed 6 years ago by
What does that (2)
instead of (0)
means? I am guessing we should go to review but we may want to fix this first.
cygwin people will have to catch later, although part of me is convinced that I shouldn't add anything at all for cygwin.
comment:34 Changed 6 years ago by
I definitely didn't correct that one properly even on linux. Fix coming.
comment:35 Changed 6 years ago by
Commit:  c027aba847298d0adc61cfc8d85a421a1df1f5b6 → b8aba3a6100241f7e63c9cd5b49579119f97ed2a 

Branch pushed to git repo; I updated commit sha1. New commits:
b8aba3a  properly fix doctest mip.pyx

comment:37 Changed 6 years ago by
Reviewers:  → Matthias Koeppe 

Status:  needs_review → positive_review 
comment:38 Changed 6 years ago by
Status:  positive_review → needs_work 

sage t long src/sage/libs/glpk/error.pyx ********************************************************************** File "src/sage/libs/glpk/error.pyx", line 98, in sage.libs.glpk.error.setup_glpk_error_handler Failed example: res = p.solve() Expected: 0: obj = ... Got: <BLANKLINE> ********************************************************************** 1 item had failures: 1 of 11 in sage.libs.glpk.error.setup_glpk_error_handler [12 tests, 1 failure, 1.34 s]
comment:39 Changed 6 years ago by
That's the test for #20832. I had forgotten about that one. It is very curious, when run at the sage prompt it gives the expected result but in the doctest we have that blank line. And of course it didn't happen with the previous version of glpk
. Any idea Jeroen?
comment:41 Changed 6 years ago by
Commit:  b8aba3a6100241f7e63c9cd5b49579119f97ed2a → 5654e49c2a02f9b3407b9249cdc4596bef95d776 

Branch pushed to git repo; I updated commit sha1. New commits:
5654e49  Merge branch 'develop' into glpk_4.60

comment:43 Changed 6 years ago by
Dependencies:  #20832 

comment:44 Changed 6 years ago by
Branch:  u/fbissey/glpk_4.60 → u/jdemeyer/glpk_4.60 

comment:45 Changed 6 years ago by
Commit:  5654e49c2a02f9b3407b9249cdc4596bef95d776 → 28ae533fbf946cf85bcd98bb3f2fc7e3ffcf3b35 

Description:  modified (diff) 
Better use an official upstream tarball instead of a repackaged one.
New commits:
adec9f8  first shot at spkgsrc for glpk

1ee3a1f  updating glpk to 4.60  first pass

3d2538e  Small improvements in spkgsrc

0b36c8b  fix doctests

9cf4d4f  Add patch for error recovery see #20710 comment 18 for detailled explanation.

f7ba9d0  Fix last doctest for 4.60

28ae533  properly fix doctest mip.pyx

comment:46 followup: 47 Changed 6 years ago by
Description:  modified (diff) 

Milestone:  sage7.3 → sage7.5 
I see. We need patches to the autoconf sources. So yes, we need a custom tarball.
comment:47 followup: 48 Changed 6 years ago by
Replying to jdemeyer:
I see. We need patches to the autoconf sources. So yes, we need a custom tarball.
Thank you, I prefer repacking rather than "custom" patches to configure, Makefile.in and al. Of course, I would prefer running autoreconf on the spot from a pristine tarball but that trade off has already been sold in sagemath.
Any ideas what is going on with the error reporting code?
comment:48 Changed 6 years ago by
Replying to fbissey:
Any ideas what is going on with the error reporting code?
I'm just building this branch now...
comment:49 Changed 6 years ago by
Commit:  28ae533fbf946cf85bcd98bb3f2fc7e3ffcf3b35 → 3e8450b13d5c5353cd45d5881acf59994cf28b6b 

Branch pushed to git repo; I updated commit sha1. New commits:
3e8450b  Fix error recovery patch

comment:50 Changed 6 years ago by
Status:  needs_work → positive_review 

Trivial fix: upstream apparently uses err_st
instead of err_file
.
comment:51 Changed 6 years ago by
Status:  positive_review → needs_review 

comment:53 Changed 6 years ago by
Status:  needs_review → positive_review 

Solves the problem here
sage t long /usr/lib64/python2.7/sitepackages/sage/libs/glpk/error.pyx [12 tests, 1.68 s]  All tests passed!
comment:54 Changed 6 years ago by
Status:  positive_review → needs_work 

5058sage t long src/sage/numerical/backends/glpk_backend.pyx 5059********************************************************************** 5060File "src/sage/numerical/backends/glpk_backend.pyx", line 912, in sage.numerical.backends.glpk_backend.GLPKBackend.solve 5061Failed example: 5062 lp.solve() 5063Expected: 5064 2.0 5065Got: 5066 glp_exact: 3 rows, 2 columns, 6 nonzeros 5067 GNU MP bignum library is being used 5068 * 2: objval = 2 (0) 5069 * 2: objval = 2 (0) 5070 OPTIMAL SOLUTION FOUND 5071 2.0 5072********************************************************************** 5073File "src/sage/numerical/backends/glpk_backend.pyx", line 944, in sage.numerical.backends.glpk_backend.GLPKBackend.solve 5074Failed example: 5075 lp.solve() == test # yes, we want an exact comparison here 5076Expected: 5077 True 5078Got: 5079 glp_exact: 1 rows, 1 columns, 1 nonzeros 5080 GNU MP bignum library is being used 5081 * 0: objval = 0 (0) 5082 * 1: objval = 9.00719925474095e+15 (0) 5083 OPTIMAL SOLUTION FOUND 5084 True 5085********************************************************************** 5086File "src/sage/numerical/backends/glpk_backend.pyx", line 1578, in sage.numerical.backends.glpk_backend.GLPKBackend.write_lp 5087Failed example: 5088 p.write_lp(os.path.join(SAGE_TMP, "lp_problem.lp")) 5089Expected nothing 5090Got: 5091 Writing problem data to '/Users/buildslavesage/slave/sage_git/dot_sage/temp/osx/98275/lp_problem.lp'... 5092 9 lines were written 5093********************************************************************** 5094File "src/sage/numerical/backends/glpk_backend.pyx", line 1598, in sage.numerical.backends.glpk_backend.GLPKBackend.write_mps 5095Failed example: 5096 p.write_mps(os.path.join(SAGE_TMP, "lp_problem.mps"), 2) 5097Expected nothing 5098Got: 5099 Writing problem data to '/Users/buildslavesage/slave/sage_git/dot_sage/temp/osx/98275/lp_problem.mps'... 5100 17 records were written 5101********************************************************************** 5102File "src/sage/numerical/backends/glpk_backend.pyx", line 2228, in sage.numerical.backends.glpk_backend.GLPKBackend.print_ranges 5103Failed example: 5104 p.print_ranges() 5105Expected: 5106 1 5107Got: 5108 glp_print_ranges: optimal basic solution required 5109 1 5110********************************************************************** 5111File "src/sage/numerical/backends/glpk_backend.pyx", line 2232, in sage.numerical.backends.glpk_backend.GLPKBackend.print_ranges 5112Failed example: 5113 p.print_ranges() 5114Expected: 5115 GLPK ...  SENSITIVITY ANALYSIS REPORT Page 1 5116 <BLANKLINE> 5117 Problem: 5118 Objective: 7.5 (MAXimum) 5119 <BLANKLINE> 5120 No. Row name St Activity Slack Lower bound Activity Obj coef Obj value at Limiting 5121 Marginal Upper bound range range break point variable 5122           5123 1 NU 3.00000 . Inf . 2.50000 . 5124 2.50000 3.00000 +Inf +Inf +Inf 5125 <BLANKLINE> 5126 GLPK ...  SENSITIVITY ANALYSIS REPORT Page 2 5127 <BLANKLINE> 5128 Problem: 5129 Objective: 7.5 (MAXimum) 5130 <BLANKLINE> 5131 No. Column name St Activity Obj coef Lower bound Activity Obj coef Obj value at Limiting 5132 Marginal Upper bound range range break point variable 5133           5134 1 NL . 2.00000 . Inf Inf +Inf 5135 .50000 +Inf 3.00000 2.50000 6.00000 5136 <BLANKLINE> 5137 2 BS 1.50000 5.00000 . Inf 4.00000 6.00000 5138 . +Inf 1.50000 +Inf +Inf 5139 <BLANKLINE> 5140 End of report 5141 <BLANKLINE> 5142 0 5143Got: 5144 Write sensitivity analysis report to '/Users/buildslavesage/slave/sage_git/dot_sage/temp/osx/98275/ranges.tmp'... 5145 GLPK 4.60  SENSITIVITY ANALYSIS REPORT Page 1 5146 <BLANKLINE> 5147 Problem: 5148 Objective: 7.5 (MAXimum) 5149 <BLANKLINE> 5150 No. Row name St Activity Slack Lower bound Activity Obj coef Obj value at Limiting 5151 Marginal Upper bound range range break point variable 5152           5153 1 NU 3.00000 . Inf . 2.50000 . 5154 2.50000 3.00000 +Inf +Inf +Inf 5155 <BLANKLINE> 5156 GLPK 4.60  SENSITIVITY ANALYSIS REPORT Page 2 5157 <BLANKLINE> 5158 Problem: 5159 Objective: 7.5 (MAXimum) 5160 <BLANKLINE> 5161 No. Column name St Activity Obj coef Lower bound Activity Obj coef Obj value at Limiting 5162 Marginal Upper bound range range break point variable 5163           5164 1 NL . 2.00000 . Inf Inf +Inf 5165 .50000 +Inf 3.00000 2.50000 6.00000 5166 <BLANKLINE> 5167 2 BS 1.50000 5.00000 . Inf 4.00000 6.00000 5168 . +Inf 1.50000 +Inf +Inf 5169 <BLANKLINE> 5170 End of report 5171 <BLANKLINE> 5172 <BLANKLINE> 5173 0 5174********************************************************************** 51754 items had failures: 5176 2 of 11 in sage.numerical.backends.glpk_backend.GLPKBackend.print_ranges 5177 2 of 76 in sage.numerical.backends.glpk_backend.GLPKBackend.solve 5178 1 of 7 in sage.numerical.backends.glpk_backend.GLPKBackend.write_lp 5179 1 of 7 in sage.numerical.backends.glpk_backend.GLPKBackend.write_mps 5180 [535 tests, 6 failures, 4.97 s]
comment:56 Changed 6 years ago by
OK something changed with this doctest in between the first time it went to the bot and now. Not sure what yet, but apart from the time limit all the corrected doctest have returned to their previous behavior in that file.
comment:57 Changed 6 years ago by
For me, all tests still pass with in the file src/sage/numerical/backends/glpk_backend.pyx
(both with and without long
).
comment:58 Changed 6 years ago by
Possible, I am seeing the change on a recent snapshot of Volker development branch on github (6th of October). So probably after the last beta was published.
comment:59 Changed 6 years ago by
I confirm the bug, Volker's output is correct: GLPK does print that output, so we should see it. So the doctests should be restored and I will look why it's failing for me.
comment:60 Changed 6 years ago by
False alarm... I was testing an older version of this branch. Good!
So we just need to restore the doctests, I'll do that right now.
comment:61 Changed 6 years ago by
Commit:  3e8450b13d5c5353cd45d5881acf59994cf28b6b → fd7afa8008652519f1bee108fd6809b1d147089d 

Branch pushed to git repo; I updated commit sha1. New commits:
fd7afa8  Fix doctests for GLPK verbose output

comment:62 Changed 6 years ago by
Status:  needs_work → needs_review 

comment:64 Changed 6 years ago by
Reviewers:  Matthias Koeppe → Matthias Koeppe, Jeroen Demeyer 

Status:  needs_review → positive_review 
Putting it back to positive review.
comment:66 Changed 6 years ago by
Branch:  u/jdemeyer/glpk_4.60 → fd7afa8008652519f1bee108fd6809b1d147089d 

Resolution:  → fixed 
Status:  positive_review → closed 
comment:67 Changed 5 years ago by
Commit:  fd7afa8008652519f1bee108fd6809b1d147089d 

It seems like glpk needs an update again in order to keep the patchbot happy. See #23777 .
comment:68 followup: 70 Changed 5 years ago by
We have to carry a very counterintuitive patch in Debian because the GLPK err_st = 0
patch was not accepted upstream. It takes me several minutes to understand what I myself wrote, every time I read it. :/
Is there any way to do the equivalent thing (err_st = 0
) in Sage instead of GLPK? I thought Cython let you access C internals.
comment:69 followup: 71 Changed 5 years ago by
Or as an alternative attempt at upstreaming this again: perhaps err_st = 0
could be conditioned so that most users of GLPK are unaffected, but Sage could pass in a special flag to GLPK to activate this behaviour just for Sage.
comment:70 Changed 5 years ago by
Replying to infinity0:
Is there any way to do the equivalent thing (
err_st = 0
) in Sage instead of GLPK?
No. Otherwise we would have done that.
I thought Cython let you access C internals.
That's true, but only C internals which are actually exposed by the library. This concerns some internal structure of GLPK which is not exposed by any API.
comment:71 Changed 5 years ago by
Replying to infinity0:
Or as an alternative attempt at upstreaming this again: perhaps
err_st = 0
could be conditioned so that most users of GLPK are unaffected
The way I understood upstream's answer is that this patch only affects uses of GLPK which are explicitly unsupported. So, by definition this patch wouldn't break any supported use cases. They don't want to accept this patch since it might imply support for something that they don't support. In the view of GLPK, Sage is using GLPK in a wrong way.
comment:72 Changed 5 years ago by
The feature in question is recovery after an error. As far as I can tell, this was first used by Sage in #12309 and we never had problems with it. So, this is a feature which seemingly works but which is unsupported. And GLPK doesn't want to accept a patch to improve something unsupported.
Maybe you could try to convince GLPK again as a Debian maintainer. Alternatively, could you convince Debian to include the Sage patch for GLPK?
Still doctests to fix.
@ jpflori could you have a look at the cygwin part? Upstream has added some stuff to add
noundefined
if host is**cygwin*
but you are also checking how gmp/mpir is built if host_os iscygwin*
at the moment I have adapted the patch but may be it is safe to drop it completely. Fromconfigure.ac
with a matching bit for
NOUNDEFINED
insrc/Makefile.am
.New commits:
first shot at spkgsrc for glpk
updating glpk to 4.60  first pass
Merge branch 'develop' into glpk_4.60