Update GLPK to 4.55

[leif]

Old versions (at least till 4.47) fail to build when link-time optimization (LTO, gcc -flto ...) is enabled.

While configure shows an error message, it continues normally and doesn't exit with an error. Only later during the build, a shell syntax error caused by libtool makes the build finally fail. New versions have been re-autotoolized with more recent autotools.

New versions also unconditionally use their own zlib, this is circumvented by patching in the spirit of what Red Hat does.

Finally we let GLPK build shared lib on Cygwin.

Upstream tarball:

• ​http://ftp.gnu.org/gnu/glpk/glpk-4.55.tar.gz

[leif]

To also motivate the upgrade:

GLPK 4.47 (release date: Sep 09, 2011)

The new API routine glp_intfeas1() was added to the package. This routine is a tentative implementation of the integer (0-1) feasibility solver based on the CNF-SAT solver (which currently is MiniSat). It may be used in the same way as glp_intopt() to find either any integer feasible solution or a solution, for which the objective function is not worse than the specified value. Detailed description of this routine can be found in the document "CNF Satisfiability Problem", which is included in the distribution (see doc/cnfsat.pdf).

The following two options were added to glpsol:

--minisat translate 0-1 feasibility problem to CNF-SAT

problem and solve it with glp_intfeas1()/MiniSat (if the problem instance is already in CNF-SAT format, no translation is performed)

--objbnd bound add inequality obj <= bound (minimization) or

obj >= bound (maximization) to 0-1 feasibility problem (this option assumes --minisat)

The paint-by-numbers puzzle model (pbn.mod) included in the distribution is a nice example of the 0-1 feasibility problem, which can be efficiently solved with glp_intfeas1()/MiniSat. This model along with a brief instruction (pbn.pdf) and benchmark examples from <webpbn.com> encoded in GNU MathProg (*.dat) can be found in subdirectory examples/pbn/.

The glpsol lp/mip solver was modified to bypass postprocessing of MathProg models if the solution reported is neither optimal nor feasible.

A minor bug in examples/Makefile.am was fixed to correctly build glpk in a separate directory. Thanks to Marco Atzeri <marco.atzeri@…> for bug report and patch.

GLPK 4.46 (release date: Aug 09, 2011)

The following new API routines were added:

glp_read_cnfsat() read CNF-SAT problem data in DIMACS format glp_check_cnfsat() check for CNF-SAT problem instance glp_write_cnfsat() write CNF-SAT problem data in DIMACS format glp_minisat1() solve CNF-SAT problem instance with MiniSat

The routine glp_minisat1() is a driver to MiniSat, a CNF-SAT solver developed by Niklas Een and Niklas Sorensson, Chalmers University of Technology, Sweden. This routine is similar to the routine glp_intopt(), however, it is intended to solve a 0-1 programming problem instance, which is the MIP translation of a CNF-SAT problem instance.

Detailed description of these new API routines can be found in the document "CNF Satisfiability Problem", which is included in the distribution (see files doc/cnfsat.tex and doc/cnfsat.pdf).

The following new glpsol command-line options were added:

--cnf filename read CNF-SAT problem instance in DIMACS

format from filename and translate it to MIP

--wcnf filename write CNF-SAT problem instance in DIMACS

format to filename

--minisat solve CNF-SAT problem instance with MiniSat

solver

The zlib compression library (version 1.2.5) was ANSIfied, modified according to GLPK requirements and included in the distribution as an external software module. Thus, now this feature is platform independent.

Some bugs were fixed in the SQL table driver. Thanks to Xypron <xypron.glpk@…>.

GLPK 4.45 (release date: Dec 05, 2010)

This is a bug-fix release.

Several bugs/typos were fixed. Thanks to Xypron <xypron.glpk@…>, Robbie Morrison <robbie@…>, and Ali Baharev <ali.baharev@…> for reports.

Some glpk documents was re-formatted and merged into a single document. Now the glpk documentation consists of the following three main documents (all included in the distribution):

GLPK: Reference Manual

GLPK: Graph and Network Routines

Modeling Language GNU MathProg: Language Reference

[leif]

The new p1 spkg fixes a potential error if CPPFLAGS aren't exported. (sage-env currently doesn't export CPPFLAGS, which I assumed it also does.)

[ncohen]

Well, this one works on my computer, and all tests pass in graph/ and numerical/ folders :-)

Nathann

[leif]

Diff between the previous spkg in Sage and my new p1 spkg. For reference / review only.

[leif]

Replying to ncohen:

Well, this one works on my computer, and all tests pass in graph/ and numerical/ folders :-)

Fine. If the new 4.47 version works faster for you (or you need / like some of its new features), feel free to increase the ticket's priority from "minor" to "major", say. :-)

(I personally would make it a blocker, since I meanwhile always build Sage with LTO, and GLPK is the only spkg in Sage that fails with that, but I'm not the release manager...)

[SimonKing]

I am currently making an experiment with sage-5.0.beta8:

• Use the modified ppl package from #12672
• Use the optional cloog_ppl spkg from #12666
• Use a new libelf spkg (not posted yet)
• Modify the gcc spkg from #12369 such that it is built with graphite and lto support
• Use the glpk spkg from here
• Build Sage (or at least the parts that come after the gcc spkg) with -O2 -march=native -flto, and perhaps in another experiment also with -floop*.
• Test whether -flto actually yields code that is noticeably faster in, say, sage -testall.

[leif]

Slightly off the ticket's topic:

Replying to SimonKing:

I am currently making an experiment with sage-5.0.beta8:

beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded gcc or g++ (Lcalc, Singular and ratpoints). I'm working on a fixed GAP spkg at #7041 as well. Andrew Ohana has some fixed zn_poly spkg (its ticket set to "needs work", but the spkg there being likely to work for you as is).

(These packages will fail to build if your "default" gcc/g++, the ones found along your PATH, don't understand the options intended for $CC/$CXX.)

• Use the modified ppl package from #12672

I've so far only tried with a GCC built with PPL 0.12. With -floop-flatten, I get PPL errors for GSL, PALP and rubiks, and PARI's test suite fails (as well as libs/pari/gen.pyx if the PARI package was built with that); the other options work.

• Modify the gcc spkg from #12369 such that it is built with graphite and lto support

Both should be enabled by default (provided GCC finds the prerequisites); haven't looked how Jeroen configures, though.

• Test whether -flto actually yields code that is noticeably faster in, say, sage -testall.

I don't think you'll see overwhelming speedup; individual tests (and other code) might run significantly faster.

Compile time is very likely to increase, since with LTO you effectively compile twice, and object files will of course get larger. (The GCC you build might be faster than your default one, though, so probably hard to compare.) Also note that -g, i.e., meaningful debugging, is said to currently not work well with LTO. (But specifying -g in addition doesn't lead to errors; a couple of packages add it by themselves.)

(Some packages or parts of them ignore CFLAGS you provide, so won't benefit from loop optimization and LTO at all. To use LTO for static libraries -- upon linking to them -- as well, you need GNU ld >= 2.21 and have to specify -fuse-linker-plugin.)

[leif]

Replying to leif:

beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded gcc or g++ (Lcalc, Singular and ratpoints). I'm working on a fixed GAP spkg at #7041 as well. Andrew Ohana has some fixed zn_poly spkg (its ticket set to "needs work", but the spkg there being likely to work for you as is).

See #12433 for the zn_poly spkg.

[SimonKing]

Replying to leif:

Slightly off the ticket's topic:

Replying to SimonKing:

I am currently making an experiment with sage-5.0.beta8:

beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded gcc or g++ (Lcalc, Singular and ratpoints).

Thank you for your hint! Indeed, Singular failed to build (more precisely: to link) with C(XX)FLAGS="-O2 -march=native -flto", but did work with -O3 -march=native`.

I'm working on a fixed GAP spkg at #7041 as well. Andrew Ohana has some fixed zn_poly spkg (its ticket set to "needs work", but the spkg there being likely to work for you as is).

(These packages will fail to build if your "default" gcc/g++, the ones found along your PATH, don't understand the options intended for $CC/$CXX.)

I'm looking forward :(

• Modify the gcc spkg from #12369 such that it is built with graphite and lto support

Both should be enabled by default (provided GCC finds the prerequisites); haven't looked how Jeroen configures, though.

The problem seems to be that gcc does not automatically picks up the installed packages. So, my suggestion is to test in spkg-install what parts of ppl, cloog-ppl and libelf are installed, and modify the options passed to ./configure (such as --with-cloog=... --enable-lto) accordingly. But this is not done yet. Also, currently one can only say via an environment variable: "Build sage with the gcc spkg." But one can not say "Build cloog-ppl and libelf first!".

What I would like to see is a syntax like

$ make cloog_ppl libelf gcc all

which would automatically try to download (to be created) optional cloog_ppl and libelf spkgs, build them, then build gcc, and then proceed with the rest of Sage.

I don't think you'll see overwhelming speedup; individual tests (and other code) might run significantly faster.

-march=native only resulted in 3% gain...

Compile time is very likely to increase, since with LTO you effectively compile twice, and object files will of course get larger. (The GCC you build might be faster than your default one, though, so probably hard to compare.)

The default one on my system does not support lto or graphite.

[SimonKing]

Replying to SimonKing:

What I would like to see is a syntax like

$ make cloog_ppl libelf gcc all

which would automatically try to download (to be created) optional cloog_ppl and libelf spkgs, build them, ...

... and of course build their dependencies first!

[SimonKing]

Replying to leif:

beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded gcc or g++ (Lcalc, Singular and ratpoints).

On second thought: I can hardly believe that, because previously I did successfully build all of Sage with -floop* flags -- and my system gcc comes without graphite. So, apparently the gcc from the spkg was picked up be Lcalc, Singular and ratpoints.

[SimonKing]

For the record: When building Sage with the gcc spkg (modified to support loop optimization and lto) and -O2 -march=native -flto then Singular failed to build (the linker produced an error). Then, I removed -flto and manually installed the Singular spkg. Finally, I reinstated -flto and successfully built the rest of Sage.

Anyway, I found no problem in building Lcalc or zn_poly or ratpoints. I did not do run the test suite yet, because technically the installation isn't over: The reference manual is now being built.

[leif]

Replying to SimonKing:

Replying to leif:

beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded gcc or g++ (Lcalc, Singular and ratpoints).

On second thought: I can hardly believe that, because previously I did successfully build all of Sage with -floop* flags -- and my system gcc comes without graphite. So, apparently the gcc from the spkg was picked up be Lcalc, Singular and ratpoints.

Well, if you happen to have the desired gcc/g++ [first] in your PATH (which certainly should be the case for Sage's GCC), it is picked up. But if you only set e.g. CC=gcc-4.6.3 etc., these packages use whatever command -v gcc etc. yield, i.e., either the system-wide default one, or Sage's in case it is installed.

FWIW, you can of course also just copy these new spkgs into spkg/standard/ of your preferred Sage installation.

[SimonKing]

Replying to leif:

Well, if you happen to have the desired gcc/g++ [first] in your PATH (which certainly should be the case for Sage's GCC), it is picked up. But if you only set e.g. CC=gcc-4.6.3 etc., these packages use whatever command -v gcc etc. yield, i.e., either the system-wide default one, or Sage's in case it is installed.

No, I have not CC defined anywhere, and indeed the freshly built gcc in SAGE_LOCAL/bin is used. Nevertheless, Singular did fail to build with the -flto flag. I suppose that means I should test with beta9, and open another ticket if it fails, right?

[SimonKing]

I had a short communication with Hans Schönemann (Singular developer) and he said it is important that the -flto flag is not only part of CCFLAGS but also of LDFLAGS. But I did not define LDFLAGS. Hence, as soon as I know how long sage -testall needs in the given setting, I will download sage-5.0.beta9, and try again, but this time with adding LDFLAGS=-lto.

[leif]

Replying to SimonKing:

Nevertheless, Singular did fail to build with the -flto flag. I suppose that means I should test with beta9, and open another ticket if it fails, right?

Works for me (with a separate GCC), so probably Sage's GCC spkg needs work.

W.r.t. -flto in LDFLAGS: You don't have to add it there for most packages, only some may need this in addition (also -fuse-linker-plugin btw.).

In any case, if you omit it, the build must not fail. Only LTO may simply not happen.

[SimonKing]

For the record: With my attempt to build sage-5.0.beta9 plus gcc with graphite and lto support and with -flto, the original GLPK spkg did not build (that is what this ticket is about) -- but apparently the spkg from here did build!

[leif]

Replying to SimonKing:

with -flto, the original GLPK spkg did not build (that is what this ticket is about)

That's correct.

but apparently the spkg from here did build!

As it should. :-)

[SimonKing]

But helas, even the new Singular spkg from 5.0-beta9 (namely singular-3-1-3-3.p6.spkg) failed to build. I used

king@mpc622:/mnt/local/king/SAGE/testinggcc/lto/sage-5.0.beta9$ echo $LDFLAGS
-flto
king@mpc622:/mnt/local/king/SAGE/testinggcc/lto/sage-5.0.beta9$ echo $CFLAGS
-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing -flto
king@mpc622:/mnt/local/king/SAGE/testinggcc/lto/sage-5.0.beta9$ echo $CXXFLAGS
-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing -flto

Is there a ticket to enable Singular with -flto? Namely, the -floop options have not been a problem when I recently tried.

[leif]

Replying to SimonKing:

But helas, even the new Singular spkg from 5.0-beta9 (namely singular-3-1-3-3.p6.spkg) failed to build. Is there a ticket to enable Singular with -flto? Namely, the -floop options have not been a problem when I recently tried.

Works for me (also with LDFLAGS=-flto).

Can you open a ticket and/or put your spkg log (t|somew)here?

[leif]

Replying to leif:

Can you open a ticket and/or put your spkg log (t|somew)here?

P.S.: If the build error is reproducible with that, preferably with MAKE="make -j1", as the flood of warnings already messes up the log.

Btw., parts of Singular still seem to disrespect CXXFLAGS, i.e., some C++ sources are compiled only using CPPFLAGS.

[SimonKing]

Replying to leif:

Replying to leif:

Can you open a ticket and/or put your spkg log (t|somew)here?

See #12738

P.S.: If the build error is reproducible with that, preferably with MAKE="make -j1", as the flood of warnings already messes up the log.

OK. The log that I posted at #12738 uses MAKE="make -j4", but I can try to change the parameter and build Singular again.

Btw., parts of Singular still seem to disrespect CXXFLAGS, i.e., some C++ sources are compiled only using CPPFLAGS.

OK. Then, before changing MAKE I will add CPPFLAGS.

However, what I see in the logs is that the -flto option is not passed to the linker, whereas it is passed to the compiler. Anyway, comments would be better at #12738.

[SimonKing]

See #12741: I found a similar problem with R.

[jpflori]

Upstream is now at 4.55.

[jpflori]

For GLPK included zlib, see Fedora's choice: ​http://pkgs.fedoraproject.org/cgit/glpk.git/commit/?id=f00815ed66d7e71c48afba9cdcb20575a49c38bd

[jpflori]

What version of autotools did you use to reconfigure the build system? Even with quite recent ones, I still get a failing behavior... That is a test with nm fails iduring configure, but the build goes on and fails during the final linking.

[jpflori]

(That is when trying to build with "CFLAGS=-flto ./sage -flto glpk" with glpk 4.55.)

[jpflori]

I attached the spkg-src script used...

[jpflori]

Ok, using CC=gcc -flto works...

[jpflori]

But it seems GLPK does not care about CC.

[jpflori]

Or I just don't know enough about LTO to understand anything.

[jpflori]

Ok, in fact, the behovior of libtool changes when CC=gcc -flto, in particular the bugging nm command with pipes includes some gnu_lto thingy.

[jpflori]

@leif: some feedback? At the moment I'll assume that CC=gcc -flto is the way to go, so upstream version 4.55 is ok.

[leif]

Replying to jpflori:

What version of autotools did you use to reconfigure the build system?

Sorry for the delay...

I think I meanwhile do not even have the machine I tested this on. But the versions I used should be reproducible from the autotools-generated files [in my spkg]... ;-)

Even with quite recent ones, I still get a failing behavior... That is a test with nm fails iduring configure, but the build goes on and fails during the final linking.

That pretty much sounds like the original failure.

FWIW, I don't think I ever used -flto as part of CC, "just" in CFLAGS and LDFLAGS.

Does your linker (and compiler) at all support LTO? (GCC version? binutils version?)

I'll see whether I find the time to look into this again the next days; certainly not today, and presumably not tomorrow.

[jpflori]

Everything I used was quite recent:

• GCC 4.9.2
• GNU nm version 2.23.51.0.1-7.fc18 20120806, not so new but should support LTO (also note this ticket started back earlier than march 2012...)
• Debian experimental autotools (not sure of the version but definitely post 2010/2012)

[jpflori]

Could you give the upstream GLPK 4.55 a try? The autotools stuff in there should be quite recent and so have no reason to fail.

[leif]

Ahem, from SPKG.txt:

To update the autotools[-generated] files, do the following: 
 
    cd src/ 
    libtoolize --copy --force 
    aclocal -I m4 
    autoconf 
    autoheader 
    automake --add-missing --copy 

(You'll of course need current versions of m4, libtool, autoconf and 
automake to produce files that support/work with LTO.  To check this, 
it is sufficient to try `CFLAGS="-flto" ./configure && make`; you need 
a recent version of GCC supporting LTO as well.) 

And don't forget to afterwards remove left-over temporary files: 

    make distclean 
    rm -rf autom4te.cache config.h.in~ 

(I used m4 1.4.16, libtool 2.4.2, autoconf 2.68 and automake 1.11.3 
to update the files for the glpk-4.47.p0 spkg.) -leif (03/2012) 

[jpflori]

I don't get your post...

I for sure ran autoreconf -fiv which is basically a one-liner for your commands, and anyway should not be needed with GLPK 4.55 which was (auto)-reconfigured upstream.

[jpflori]

I you just wanted to point out that building with CFLAGS=-flto should work, then something very fishy is going on... Or it's just that binutils 2.23 don't support LTO :)

[leif]

Replying to jpflori:

I don't get your post...

Well, that wasn't a reply to your latest posts.

I for sure ran autoreconf -fiv which is basically a one-liner for your commands, and anyway should not be needed with GLPK 4.55 which was (auto)-reconfigured upstream.

I'll try 4.55 later, but my autoreconfed 4.47 should in principle work as well. Unless something else got messed up elsewhere, later.

---

Could you post the exact error you got?

[jpflori]

I checked that on my systems all the autotools stuff are recent enough, so it is not the problem, unless newer version of some of these tools got broken back.

I think it is the original error you got back in 2012. Basically looking like what I saw here:

• ​http://lists.gnu.org/archive/html/bug-glpk/2012-03/msg00000.html

During configure, a test involving nm -B parsing the output of GCC fails, and then during make:

make[2]: Entering directory '/home/jp/glpk/src/src'
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -flto -version-info 37:2:1 -export-symbols-regex '^glp_*'   -o libglpk.la -rpath /usr/local/lib libglpk_la-avl.lo libglpk_la-bfd.lo libglpk_la-bfx.lo libglpk_la-glpapi01.lo libglpk_la-glpapi02.lo libglpk_la-glpapi03.lo libglpk_la-glpapi04.lo libglpk_la-glpapi05.lo libglpk_la-glpapi06.lo libglpk_la-glpapi07.lo libglpk_la-glpapi08.lo libglpk_la-glpapi09.lo libglpk_la-glpapi10.lo libglpk_la-glpapi11.lo libglpk_la-glpapi12.lo libglpk_la-glpapi13.lo libglpk_la-glpapi14.lo libglpk_la-glpapi15.lo libglpk_la-glpapi16.lo libglpk_la-glpapi17.lo libglpk_la-glpapi18.lo libglpk_la-glpapi19.lo libglpk_la-glpapi20.lo libglpk_la-glpapi21.lo libglpk_la-glpcpx.lo libglpk_la-glpdmx.lo libglpk_la-glpgmp.lo libglpk_la-glphbm.lo libglpk_la-glpini01.lo libglpk_la-glpini02.lo libglpk_la-glpios01.lo libglpk_la-glpios02.lo libglpk_la-glpios03.lo libglpk_la-glpios04.lo libglpk_la-glpios05.lo libglpk_la-glpios06.lo libglpk_la-glpios07.lo libglpk_la-glpios08.lo libglpk_la-glpios09.lo libglpk_la-glpios10.lo libglpk_la-glpios11.lo libglpk_la-glpios12.lo libglpk_la-glpipm.lo libglpk_la-glpmat.lo libglpk_la-glpmpl01.lo libglpk_la-glpmpl02.lo libglpk_la-glpmpl03.lo libglpk_la-glpmpl04.lo libglpk_la-glpmpl05.lo libglpk_la-glpmpl06.lo libglpk_la-glpmps.lo libglpk_la-glpnet03.lo libglpk_la-glpnet04.lo libglpk_la-glpnet05.lo libglpk_la-glpnpp01.lo libglpk_la-glpnpp02.lo libglpk_la-glpnpp03.lo libglpk_la-glpnpp04.lo libglpk_la-glpnpp05.lo libglpk_la-glpnpp06.lo libglpk_la-glprgr.lo libglpk_la-glpscl.lo libglpk_la-glpsdf.lo libglpk_la-glpspm.lo libglpk_la-glpspx01.lo libglpk_la-glpspx02.lo libglpk_la-glpsql.lo libglpk_la-glpssx01.lo libglpk_la-glpssx02.lo libglpk_la-glptsp.lo libglpk_la-lux.lo libglpk_la-amd_1.lo libglpk_la-amd_2.lo libglpk_la-amd_aat.lo libglpk_la-amd_control.lo libglpk_la-amd_defaults.lo libglpk_la-amd_dump.lo libglpk_la-amd_info.lo libglpk_la-amd_order.lo libglpk_la-amd_post_tree.lo libglpk_la-amd_postorder.lo libglpk_la-amd_preprocess.lo libglpk_la-amd_valid.lo libglpk_la-btf.lo libglpk_la-btfint.lo libglpk_la-fhv.lo libglpk_la-fhvint.lo libglpk_la-ifu.lo libglpk_la-luf.lo libglpk_la-lufint.lo libglpk_la-scf.lo libglpk_la-scfint.lo libglpk_la-sgf.lo libglpk_la-sva.lo libglpk_la-cfg.lo libglpk_la-cfg1.lo libglpk_la-colamd.lo libglpk_la-alloc.lo libglpk_la-dlsup.lo libglpk_la-env.lo libglpk_la-error.lo libglpk_la-stdout.lo libglpk_la-stream.lo libglpk_la-time.lo libglpk_la-tls.lo libglpk_la-minisat.lo libglpk_la-bignum.lo libglpk_la-dmp.lo libglpk_la-ffalg.lo libglpk_la-fp2rat.lo libglpk_la-gcd.lo libglpk_la-jd.lo libglpk_la-keller.lo libglpk_la-mc13d.lo libglpk_la-mc21a.lo libglpk_la-okalg.lo libglpk_la-qmd.lo libglpk_la-relax4.lo libglpk_la-rng.lo libglpk_la-rng1.lo libglpk_la-round2n.lo libglpk_la-str2int.lo libglpk_la-str2num.lo libglpk_la-strspx.lo libglpk_la-strtrim.lo libglpk_la-triang.lo libglpk_la-wclique.lo libglpk_la-wclique1.lo libglpk_la-proxy.lo libglpk_la-proxy1.lo -lz -lm 
libtool: link: /usr/bin/nm -B  .libs/libglpk_la-avl.o .libs/libglpk_la-bfd.o .libs/libglpk_la-bfx.o .libs/libglpk_la-glpapi01.o .libs/libglpk_la-glpapi02.o .libs/libglpk_la-glpapi03.o .libs/libglpk_la-glpapi04.o .libs/libglpk_la-glpapi05.o .libs/libglpk_la-glpapi06.o .libs/libglpk_la-glpapi07.o .libs/libglpk_la-glpapi08.o .libs/libglpk_la-glpapi09.o .libs/libglpk_la-glpapi10.o .libs/libglpk_la-glpapi11.o .libs/libglpk_la-glpapi12.o .libs/libglpk_la-glpapi13.o .libs/libglpk_la-glpapi14.o .libs/libglpk_la-glpapi15.o .libs/libglpk_la-glpapi16.o .libs/libglpk_la-glpapi17.o .libs/libglpk_la-glpapi18.o .libs/libglpk_la-glpapi19.o .libs/libglpk_la-glpapi20.o .libs/libglpk_la-glpapi21.o .libs/libglpk_la-glpcpx.o .libs/libglpk_la-glpdmx.o .libs/libglpk_la-glpgmp.o .libs/libglpk_la-glphbm.o .libs/libglpk_la-glpini01.o .libs/libglpk_la-glpini02.o .libs/libglpk_la-glpios01.o .libs/libglpk_la-glpios02.o .libs/libglpk_la-glpios03.o .libs/libglpk_la-glpios04.o .libs/libglpk_la-glpios05.o .libs/libglpk_la-glpios06.o .libs/libglpk_la-glpios07.o .libs/libglpk_la-glpios08.o .libs/libglpk_la-glpios09.o .libs/libglpk_la-glpios10.o .libs/libglpk_la-glpios11.o .libs/libglpk_la-glpios12.o .libs/libglpk_la-glpipm.o .libs/libglpk_la-glpmat.o .libs/libglpk_la-glpmpl01.o .libs/libglpk_la-glpmpl02.o .libs/libglpk_la-glpmpl03.o .libs/libglpk_la-glpmpl04.o .libs/libglpk_la-glpmpl05.o .libs/libglpk_la-glpmpl06.o .libs/libglpk_la-glpmps.o .libs/libglpk_la-glpnet03.o .libs/libglpk_la-glpnet04.o .libs/libglpk_la-glpnet05.o .libs/libglpk_la-glpnpp01.o .libs/libglpk_la-glpnpp02.o .libs/libglpk_la-glpnpp03.o .libs/libglpk_la-glpnpp04.o .libs/libglpk_la-glpnpp05.o .libs/libglpk_la-glpnpp06.o .libs/libglpk_la-glprgr.o .libs/libglpk_la-glpscl.o .libs/libglpk_la-glpsdf.o .libs/libglpk_la-glpspm.o .libs/libglpk_la-glpspx01.o .libs/libglpk_la-glpspx02.o .libs/libglpk_la-glpsql.o .libs/libglpk_la-glpssx01.o .libs/libglpk_la-glpssx02.o .libs/libglpk_la-glptsp.o .libs/libglpk_la-lux.o .libs/libglpk_la-amd_1.o .libs/libglpk_la-amd_2.o .libs/libglpk_la-amd_aat.o .libs/libglpk_la-amd_control.o .libs/libglpk_la-amd_defaults.o .libs/libglpk_la-amd_dump.o .libs/libglpk_la-amd_info.o .libs/libglpk_la-amd_order.o .libs/libglpk_la-amd_post_tree.o .libs/libglpk_la-amd_postorder.o .libs/libglpk_la-amd_preprocess.o .libs/libglpk_la-amd_valid.o .libs/libglpk_la-btf.o .libs/libglpk_la-btfint.o .libs/libglpk_la-fhv.o .libs/libglpk_la-fhvint.o .libs/libglpk_la-ifu.o .libs/libglpk_la-luf.o .libs/libglpk_la-lufint.o .libs/libglpk_la-scf.o .libs/libglpk_la-scfint.o .libs/libglpk_la-sgf.o .libs/libglpk_la-sva.o .libs/libglpk_la-cfg.o .libs/libglpk_la-cfg1.o .libs/libglpk_la-colamd.o .libs/libglpk_la-alloc.o .libs/libglpk_la-dlsup.o .libs/libglpk_la-env.o .libs/libglpk_la-error.o .libs/libglpk_la-stdout.o .libs/libglpk_la-stream.o .libs/libglpk_la-time.o .libs/libglpk_la-tls.o .libs/libglpk_la-minisat.o .libs/libglpk_la-bignum.o .libs/libglpk_la-dmp.o .libs/libglpk_la-ffalg.o .libs/libglpk_la-fp2rat.o .libs/libglpk_la-gcd.o .libs/libglpk_la-jd.o .libs/libglpk_la-keller.o .libs/libglpk_la-mc13d.o .libs/libglpk_la-mc21a.o .libs/libglpk_la-okalg.o .libs/libglpk_la-qmd.o .libs/libglpk_la-relax4.o .libs/libglpk_la-rng.o .libs/libglpk_la-rng1.o .libs/libglpk_la-round2n.o .libs/libglpk_la-str2int.o .libs/libglpk_la-str2num.o .libs/libglpk_la-strspx.o .libs/libglpk_la-strtrim.o .libs/libglpk_la-triang.o .libs/libglpk_la-wclique.o .libs/libglpk_la-wclique1.o .libs/libglpk_la-proxy.o .libs/libglpk_la-proxy1.o   |  | /bin/sed 's/.* //' | sort | uniq > .libs/libglpk.exp
../libtool: eval: line 1088: syntax error near unexpected token `|'
../libtool: eval: line 1088: `/usr/bin/nm -B  .libs/libglpk_la-avl.o .libs/libglpk_la-bfd.o .libs/libglpk_la-bfx.o .libs/libglpk_la-glpapi01.o .libs/libglpk_la-glpapi02.o .libs/libglpk_la-glpapi03.o .libs/libglpk_la-glpapi04.o .libs/libglpk_la-glpapi05.o .libs/libglpk_la-glpapi06.o .libs/libglpk_la-glpapi07.o .libs/libglpk_la-glpapi08.o .libs/libglpk_la-glpapi09.o .libs/libglpk_la-glpapi10.o .libs/libglpk_la-glpapi11.o .libs/libglpk_la-glpapi12.o .libs/libglpk_la-glpapi13.o .libs/libglpk_la-glpapi14.o .libs/libglpk_la-glpapi15.o .libs/libglpk_la-glpapi16.o .libs/libglpk_la-glpapi17.o .libs/libglpk_la-glpapi18.o .libs/libglpk_la-glpapi19.o .libs/libglpk_la-glpapi20.o .libs/libglpk_la-glpapi21.o .libs/libglpk_la-glpcpx.o .libs/libglpk_la-glpdmx.o .libs/libglpk_la-glpgmp.o .libs/libglpk_la-glphbm.o .libs/libglpk_la-glpini01.o .libs/libglpk_la-glpini02.o .libs/libglpk_la-glpios01.o .libs/libglpk_la-glpios02.o .libs/libglpk_la-glpios03.o .libs/libglpk_la-glpios04.o .libs/libglpk_la-glpios05.o .libs/libglpk_la-glpios06.o .libs/libglpk_la-glpios07.o .libs/libglpk_la-glpios08.o .libs/libglpk_la-glpios09.o .libs/libglpk_la-glpios10.o .libs/libglpk_la-glpios11.o .libs/libglpk_la-glpios12.o .libs/libglpk_la-glpipm.o .libs/libglpk_la-glpmat.o .libs/libglpk_la-glpmpl01.o .libs/libglpk_la-glpmpl02.o .libs/libglpk_la-glpmpl03.o .libs/libglpk_la-glpmpl04.o .libs/libglpk_la-glpmpl05.o .libs/libglpk_la-glpmpl06.o .libs/libglpk_la-glpmps.o .libs/libglpk_la-glpnet03.o .libs/libglpk_la-glpnet04.o .libs/libglpk_la-glpnet05.o .libs/libglpk_la-glpnpp01.o .libs/libglpk_la-glpnpp02.o .libs/libglpk_la-glpnpp03.o .libs/libglpk_la-glpnpp04.o .libs/libglpk_la-glpnpp05.o .libs/libglpk_la-glpnpp06.o .libs/libglpk_la-glprgr.o .libs/libglpk_la-glpscl.o .libs/libglpk_la-glpsdf.o .libs/libglpk_la-glpspm.o .libs/libglpk_la-glpspx01.o .libs/libglpk_la-glpspx02.o .libs/libglpk_la-glpsql.o .libs/libglpk_la-glpssx01.o .libs/libglpk_la-glpssx02.o .libs/libglpk_la-glptsp.o .libs/libglpk_la-lux.o .libs/libglpk_la-amd_1.o .libs/libglpk_la-amd_2.o .libs/libglpk_la-amd_aat.o .libs/libglpk_la-amd_control.o .libs/libglpk_la-amd_defaults.o .libs/libglpk_la-amd_dump.o .libs/libglpk_la-amd_info.o .libs/libglpk_la-amd_order.o .libs/libglpk_la-amd_post_tree.o .libs/libglpk_la-amd_postorder.o .libs/libglpk_la-amd_preprocess.o .libs/libglpk_la-amd_valid.o .libs/libglpk_la-btf.o .libs/libglpk_la-btfint.o .libs/libglpk_la-fhv.o .libs/libglpk_la-fhvint.o .libs/libglpk_la-ifu.o .libs/libglpk_la-luf.o .libs/libglpk_la-lufint.o .libs/libglpk_la-scf.o .libs/libglpk_la-scfint.o .libs/libglpk_la-sgf.o .libs/libglpk_la-sva.o .libs/libglpk_la-cfg.o .libs/libglpk_la-cfg1.o .libs/libglpk_la-colamd.o .libs/libglpk_la-alloc.o .libs/libglpk_la-dlsup.o .libs/libglpk_la-env.o .libs/libglpk_la-error.o .libs/libglpk_la-stdout.o .libs/libglpk_la-stream.o .libs/libglpk_la-time.o .libs/libglpk_la-tls.o .libs/libglpk_la-minisat.o .libs/libglpk_la-bignum.o .libs/libglpk_la-dmp.o .libs/libglpk_la-ffalg.o .libs/libglpk_la-fp2rat.o .libs/libglpk_la-gcd.o .libs/libglpk_la-jd.o .libs/libglpk_la-keller.o .libs/libglpk_la-mc13d.o .libs/libglpk_la-mc21a.o .libs/libglpk_la-okalg.o .libs/libglpk_la-qmd.o .libs/libglpk_la-relax4.o .libs/libglpk_la-rng.o .libs/libglpk_la-rng1.o .libs/libglpk_la-round2n.o .libs/libglpk_la-str2int.o .libs/libglpk_la-str2num.o .libs/libglpk_la-strspx.o .libs/libglpk_la-strtrim.o .libs/libglpk_la-triang.o .libs/libglpk_la-wclique.o .libs/libglpk_la-wclique1.o .libs/libglpk_la-proxy.o .libs/libglpk_la-proxy1.o   |  | /bin/sed 's/.* //' | sort | uniq > .libs/libglpk.exp'

[leif]

Replying to jpflori:

I you just wanted to point out that building with CFLAGS=-flto should work, then something very fishy is going on...

Yep, CFLAGS=-flto should work, provided your compiler and linker support it (binutils at least >=2.22 should, GCC needs to be configured accordingly -- AFAIK Sage's isn't). Not sure right now whether LDFLAGS=-flto [-fuse-linker-plugin] was needed, too, but in any case omitting it shouldn't cause any error.

Or it's just that binutils 2.23 don't support LTO :)

They should.

[jpflori]

Replying to leif:

Replying to jpflori:

I you just wanted to point out that building with CFLAGS=-flto should work, then something very fishy is going on...

Yep, CFLAGS=-flto should work, provided your compiler and linker support it (binutils at least >=2.22 should, GCC needs to be configured accordingly -- AFAIK Sage's isn't).

What should I look for in gcc -v? My debian's one spits:

% gcc -v                                                                                                                                     ~/glpk/src
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-19' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-19)

[jpflori]

In fact in config.log I see:

configure:4682: gcc -c -flto  conftest.c >&5
configure:4685: /usr/bin/nm -B "conftest.o"
/usr/bin/nm: conftest.o: plugin needed to handle lto object
configure:4688: output
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1
...
configure:5616: checking for archiver @FILE support
configure:5633: gcc -c -flto  conftest.c >&5
configure:5633: $? = 0
configure:5636: ar cru libconftest.a @conftest.lst >&5
BFD: conftest.o: plugin needed to handle lto object
configure:5639: $? = 0
configure:5644: ar cru libconftest.a @conftest.lst >&5
ar: conftest.o: No such file or directory
configure:5647: $? = 1
...
configure:5945: checking command to parse /usr/bin/nm -B output from gcc object
configure:6065: gcc -c -flto  conftest.c >&5
configure:6068: $? = 0
configure:6072: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm
/usr/bin/nm: conftest.o: plugin needed to handle lto object
configure:6075: $? = 0
cannot run sed -n -e 's/^.*[     ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[         ][      ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d'
configure:6065: gcc -c -flto  conftest.c >&5
configure:6068: $? = 0
configure:6072: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm
/usr/bin/nm: conftest.o: plugin needed to handle lto object
configure:6075: $? = 0
cannot run sed -n -e 's/^.*[     ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[         ][      ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d'
configure:6179: result: failed

[jpflori]

And this is nm version:

% nm --version                                                
GNU nm (GNU Binutils for Debian) 2.24.90.20141023
Copyright (C) 2014 Free Software Foundation, Inc.
Ce logiciel est libre; vous pouvez le redistribuer selon les termes de la
version 3 de la licence GNU General Public License ou (à votre discrétion

[jpflori]

Ok, it seems to be a similar issue as in:

• ​https://bugzilla.redhat.com/show_bug.cgi?id=1091611

Passing CFLAGS="-flto -ffat-lto-objects" works fine...

[leif]

Ah, so it's the French one that doesn't work! B)

(Not sure what "cannot run sed ..." is supposed to mean.)

[jpflori]

Yeah, that's boring but out of our hands. I'll just post my git branch for 4.55 including Cygwin shared lib generation and use of system zlib here tomorrow.

[leif]

FWIW, with vanilla GLPK 4.55, CFLAGS=-flto works for me with GCC 4.7.4, but fails with GCC 4.9.1 (both with binutils 2.22).

There've been major changes to LTO over time IIRC, so while the "new" errors are annoying, they're probably not too surprising.

But it's a minor issue anyway, and apparently meanwhile modifying CFLAGS is sufficient to get around the failure, as opposed to modifying the sources which previously was necessary.

Will your "spkg" be based on my previous one? (Unfortunately my home directory is no longer accessible via HTTP, so you'd have to use scp instead, say.)

[leif]

Replying to leif:

FWIW, with vanilla GLPK 4.55, CFLAGS=-flto works for me with GCC 4.7.4, but fails with GCC 4.9.1 (both with binutils 2.22).

Just for the record: With GCC 4.8.3, -flto is sufficient as well.

There've been major changes to LTO over time IIRC, so while the "new" errors are annoying, they're probably not too surprising.

[jpflori]

New commits:

​57682f2	GLPK update.
​758b53a	Update GLPK to 4.55. Keep vanilla upstream tarball.

[fbissey]

I cannot comment on the build part but the commit addresses a good number of doctest failures I have seen in sage-on-gentoo with glpk 4.54. Only one bit really need to be changed:

--- a/src/sage/numerical/mip.pyx
+++ b/src/sage/numerical/mip.pyx
@@ -2387,12 +2387,12 @@ cdef class MixedIntegerLinearProgram(SageObject):
             sage: b = p.get_backend()
             sage: b.solver_parameter("simplex_or_intopt", "simplex_only")
             sage: b.solver_parameter("verbosity_simplex", "GLP_MSG_ALL")
-            sage: p.solve()  # tol 0.00001
+            sage: p.solve()  # rel tol 3e-2
             GLPK Simplex Optimizer, v4.44
             2 rows, 2 columns, 4 non-zeros
             *     0: obj =   7.000000000e+00  infeas =  0.000e+00 (0)
             *     2: obj =   9.400000000e+00  infeas =  0.000e+00 (0)
-            OPTIMAL SOLUTION FOUND
+            OPTIMAL LP SOLUTION FOUND
             9.4
         """
         return self._backend

You still have "GLPK Simplex Optimizer, v4.44" so it seems you have forgotten that bit. I doubt it would be caught by the tolerance. My own request would be for the version to be tested as "4....".

[jdemeyer]

Replying to fbissey:

I doubt it would be caught by the tolerance.

It works: the relative tolerance of 3e-2 is sufficient to consider 4.44 and 4.55 equal.

My own request would be for the version to be tested as "4....".

Hiding floats under ... while testing with tolerance is not supported.

[jdemeyer]

The statements

* As of version 4.55, zlib is included in the GLPK sources, and *that*
version is unconditionally compiled into the GLPK library, so there's
no "external" dependency on it

and

* zlib.patch: don't build the included zlib library.

seem to contradict eachother.

[jdemeyer]

Also, CFALGS surely is a typo?

[jdemeyer]

If you add

# Exit on error
set -e

then remove all other error checking :-)

[fbissey]

Replying to jdemeyer:

Replying to fbissey:

I doubt it would be caught by the tolerance.

It works: the relative tolerance of 3e-2 is sufficient to consider 4.44 and 4.55 equal.

I think I misunderstood the tolerance. I always thought it was absolute tolerance $\Delta$x but you are saying it is relative as in $\Delta$x/x, then yes it makes it pass but it probably still should be changed.

My own request would be for the version to be tested as "4....".

Hiding floats under ... while testing with tolerance is not supported.

Now I remember about that.

[jdemeyer]

I doubt that

# The following is an easy way to prevent autotools to regenerate its files.
touch *

actually works as advertised. You're assuming that touch * will never cause configure.ac to have a newer timestamp than configure.

[jdemeyer]

With the philosophy that packages should be as close to upstream as possible, should we really add the patch the disable compiling the included zlib?

[jpflori]

Replying to jdemeyer:

I doubt that

# The following is an easy way to prevent autotools to regenerate its files.
touch *

actually works as advertised. You're assuming that touch * will never cause configure.ac to have a newer timestamp than configure.

It works for me. It could indeed fail on system where touch * will de very slow and the timestamp very precise. Trying to touch the right files by hand is a nightmare, there are just too many dependencies. I've tried reading the magical overly complicated Makefile generated by autotools but always seemed to miss something.

[jpflori]

Replying to jdemeyer:

With the philosophy that packages should be as close to upstream as possible, should we really add the patch the disable compiling the included zlib?

I think we should not compile the included zlib like we should not compile the various versions of GMP included in a bunch of packages.

[jdemeyer]

What does the "Reported upstream. Developers acknowledge bug." refer to and where is the upstream report?

[jpflori]

Replying to jdemeyer:

What does the "Reported upstream. Developers acknowledge bug." refer to and where is the upstream report?

I linked some thread from glpk list here. That should be the report. The upstream fix is that the autotools stuff was regenerated since 4.47.

[jpflori]

Replying to jpflori:

Replying to jdemeyer:

With the philosophy that packages should be as close to upstream as possible, should we really add the patch the disable compiling the included zlib?

I think we should not compile the included zlib like we should not compile the various versions of GMP included in a bunch of packages.

Also note that we ship a vanilla tarball.

[jpflori]

Replying to jdemeyer:

The statements

* As of version 4.55, zlib is included in the GLPK sources, and *that*
version is unconditionally compiled into the GLPK library, so there's
no "external" dependency on it

and

* zlib.patch: don't build the included zlib library.

seem to contradict eachother.

Indeed, I'll change the "unconditionally" by "there is no configure flag to prevent it from being" and remove the thing about dependency.

[fbissey]

I think if you are going to modify configure and co. you need to generate a new tarball for sage. Patching configure directly is not really sustainable and touching may need to be done with more care. I am quite surprised you weren't bitten by it so far considering that configure.ac comes after configure in most ordering.

[jpflori]

Replying to fbissey:

I think if you are going to modify configure and co. you need to generate a new tarball for sage. Patching configure directly is not really sustainable and touching may need to be done with more care. I am quite surprised you weren't bitten by it so far considering that configure.ac comes after configure in most ordering.

That's why I touch *. Ensuring that configure.ac was patch before configure and Makefiles.am before Makefiles.in and then playing with m4 files timestamp just drove me crazy.

[jdemeyer]

Replying to jpflori:

Ensuring that configure.ac was patch before configure and Makefiles.am before Makefiles.in and then playing with m4 files timestamp just drove me crazy.

I cannot really imagine that it's that bad: you only need to touch a few files...

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​4afb953

A few fixes for GLPK update to 4.55.

[jdemeyer]

In the "dependencies" part", you can just write

* zlib

(there is already a comment about zlib in the "Special Update/Build? Instructions")

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​b3bf953

Refrain autotools from regenerating its files when configuring GLPK.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2776a68

zlib is a dependency of GLPK as we don't use the upstream shipped version.

[jpflori]

FYI, the cygwin shared lib stuff should go upstream in one form or another. See:

• ​http://lists.gnu.org/archive/html/help-glpk/2014-11/msg00000.html

[jpflori]

There is something wrong on Cygwin with the shared lib stuff....

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0554899	Merge remote-tracking branch 'trac/develop' into ticket/12703
​468a7d8	Fix GLPK tweak for Cygwin.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​8b77569

Fix GLPK tweak for Cygwin.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​584cbd6

Fix stupid typo in previous commit for GLPK on Cygwin.

[jpflori]

Ok, this is now fixed and confirmed to work on Cygwin and ppc64. Sorry about the forced push, I included some spurious autotools stuff in the previous commit.

[vbraun]

The -0.0 looks like numerical noise, its probably better to use # abs tol 1e-15 or so. Rest looks good to me.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​c333b09	Merge remote-tracking branch 'trac/develop' into ticket/12703
​9ecce27	Modify GLPK test involving numerical noise.

[jpflori]

Tests modified.

[vbraun]

sage -t --long --warn-long 40.1 src/sage/numerical/mip.pyx
**********************************************************************
File "src/sage/numerical/mip.pyx", line 2097, in sage.numerical.mip.MixedIntegerLinearProgram.number_of_variables.solve
Failed example:
    round(x[1],6)
Expected:
    0.0
Got:
    -0.0
**********************************************************************
1 item had failures:
   1 of  24 in sage.numerical.mip.MixedIntegerLinearProgram.number_of_variables.solve
    [493 tests, 1 failure, 0.88 s]
----------------------------------------------------------------------
sage -t --long --warn-long 40.1 src/sage/numerical/mip.pyx  # 1 doctest failed
----------------------------------------------------------------------

[vbraun]

Apart from that one the buildbot didn't find any other failures.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​827eaa3

Further numerical noise after GLPK updated.

[jdemeyer]

Replying to leif:

New versions also unconditionally use their own zlib

Is this really a problem? I'm asking because this is a non-trivial patch which no longer applies against a newer GLPK (version 4.57, just released). If we don't strictly need it, I would rather remove that patch.

[fbissey]

Replying to jdemeyer:

Replying to leif:

New versions also unconditionally use their own zlib

Is this really a problem? I'm asking because this is a non-trivial patch which no longer applies against a newer GLPK (version 4.57, just released). If we don't strictly need it, I would rather remove that patch.

It is most unfortunate. In the context of sage I guess I would just remove the patch. The only way to eliminate it, is to work with upstream to make it configurable. Most distro will unbundle it in any case.

[jdemeyer]

I just don't feel motivated to maintained a patch which isn't actually needed.