Opened 8 years ago

Closed 5 years ago

Last modified 4 years ago

#12703 closed defect (fixed)

Update GLPK to 4.55

Reported by: leif Owned by: leif
Priority: minor Milestone: sage-6.4
Component: packages: standard Keywords: link time optimization nm glpsol spkg upgrade update
Cc: ncohen, SimonKing, tscrim Merged in:
Authors: Leif Leonhardy, Jean-Pierre Flori Reviewers: Nathann Cohen, Volker Braun
Report Upstream: Reported upstream. Developers acknowledge bug. Work issues:
Branch: 827eaa3 (Commits) Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

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:

Attachments (2)

glpk-4.44.p0-4.47.p1.diff (14.0 KB) - added by leif 8 years ago.
Diff between the previous spkg in Sage and my new p1 spkg. For reference / review only.
spkg-src (1.1 KB) - added by jpflori 5 years ago.

Download all attachments as: .zip

Change History (99)

comment:1 Changed 8 years ago by leif

  • Authors set to Leif Leonhardy
  • Cc ncohen SimonKing added
  • Description modified (diff)
  • Keywords upgrade update added
  • Status changed from new to needs_review

comment:2 Changed 8 years ago by 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

Last edited 8 years ago by leif (previous) (diff)

comment:3 Changed 8 years ago by leif

  • Description modified (diff)

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

comment:4 Changed 8 years ago by leif

  • Reviewers set to Nathann Cohen

comment:5 follow-up: Changed 8 years ago by ncohen

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

Nathann

Changed 8 years ago by leif

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

comment:6 in reply to: ↑ 5 Changed 8 years ago by 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...)

comment:7 Changed 8 years ago by 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.

comment:8 follow-ups: Changed 8 years ago by 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.)

comment:9 in reply to: ↑ 8 Changed 8 years ago by 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.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 8 years ago by 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.

comment:11 in reply to: ↑ 10 Changed 8 years ago by 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!

comment:12 in reply to: ↑ 8 ; follow-up: Changed 8 years ago by 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.

comment:13 Changed 8 years ago by 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.

comment:14 in reply to: ↑ 12 ; follow-up: Changed 8 years ago by 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.

comment:15 in reply to: ↑ 14 ; follow-up: Changed 8 years ago by 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?

comment:16 Changed 8 years ago by 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.

comment:17 in reply to: ↑ 15 Changed 8 years ago by 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.

comment:18 follow-up: Changed 8 years ago by 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!

comment:19 in reply to: ↑ 18 Changed 8 years ago by 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. :-)

comment:20 follow-up: Changed 8 years ago by 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.

comment:21 in reply to: ↑ 20 ; follow-up: Changed 8 years ago by 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?

comment:22 in reply to: ↑ 21 ; follow-up: Changed 8 years ago by 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.

comment:23 in reply to: ↑ 22 Changed 8 years ago by 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.

comment:24 Changed 8 years ago by SimonKing

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

comment:25 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:26 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:27 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:28 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:29 Changed 5 years ago by jpflori

Upstream is now at 4.55.

comment:31 follow-up: Changed 5 years ago by 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.

comment:32 Changed 5 years ago by jpflori

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

comment:33 Changed 5 years ago by jpflori

I attached the spkg-src script used...

Changed 5 years ago by jpflori

comment:34 Changed 5 years ago by jpflori

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

comment:35 Changed 5 years ago by jpflori

But it seems GLPK does not care about CC.

comment:36 Changed 5 years ago by jpflori

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

comment:37 Changed 5 years ago by 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.

comment:38 Changed 5 years ago by 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.

comment:39 in reply to: ↑ 31 Changed 5 years ago by 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.

comment:40 Changed 5 years ago by 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)

comment:41 Changed 5 years ago by 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.

comment:42 Changed 5 years ago by 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) 

comment:43 follow-up: Changed 5 years ago by 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.

comment:44 follow-up: Changed 5 years ago by 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 :)

comment:45 in reply to: ↑ 43 Changed 5 years ago by 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?

comment:46 Changed 5 years ago by 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:

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'

comment:47 in reply to: ↑ 44 ; follow-up: Changed 5 years ago by 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.

comment:48 in reply to: ↑ 47 Changed 5 years ago by 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)

comment:49 Changed 5 years ago by 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

comment:50 Changed 5 years ago by 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

comment:51 Changed 5 years ago by jpflori

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

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

comment:52 Changed 5 years ago by leif

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

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

comment:53 Changed 5 years ago by 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.

comment:54 follow-up: Changed 5 years ago by 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.)

comment:55 in reply to: ↑ 54 Changed 5 years ago by 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.

comment:56 Changed 5 years ago by jpflori

  • Authors changed from Leif Leonhardy to Leif Leonhardy, Jean-Pierre Flori
  • Branch set to u/jpflori/ticket/12703
  • Commit set to 758b53a7487cb405286ad009caaab733842f0f8e
  • Description modified (diff)
  • Summary changed from GLPK fails to build with LTO (`gcc -flto ...`) to Update GLPK to 4.55.

New commits:

57682f2GLPK update.
758b53aUpdate GLPK to 4.55. Keep vanilla upstream tarball.

comment:57 follow-up: Changed 5 years ago by 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....".

comment:58 in reply to: ↑ 57 ; follow-up: Changed 5 years ago by 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.

comment:59 follow-up: Changed 5 years ago by 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.

comment:60 Changed 5 years ago by jdemeyer

  • Status changed from needs_review to needs_work

Also, CFALGS surely is a typo?

comment:61 Changed 5 years ago by jdemeyer

If you add

# Exit on error
set -e

then remove all other error checking :-)

comment:62 in reply to: ↑ 58 Changed 5 years ago by 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.

comment:63 follow-up: Changed 5 years ago by 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.

comment:64 follow-up: Changed 5 years ago by jdemeyer

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

Version 0, edited 5 years ago by jdemeyer (next)

comment:65 in reply to: ↑ 63 Changed 5 years ago by 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.

comment:66 in reply to: ↑ 64 ; follow-up: Changed 5 years ago by 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.

comment:67 follow-up: Changed 5 years ago by jdemeyer

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

comment:68 in reply to: ↑ 67 Changed 5 years ago by 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.

comment:69 in reply to: ↑ 66 Changed 5 years ago by 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.

comment:70 in reply to: ↑ 59 Changed 5 years ago by 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.

comment:71 follow-up: Changed 5 years ago by 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.

comment:72 in reply to: ↑ 71 ; follow-up: Changed 5 years ago by 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.

comment:73 in reply to: ↑ 72 Changed 5 years ago by 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...

comment:74 Changed 5 years ago by git

  • Commit changed from 758b53a7487cb405286ad009caaab733842f0f8e to 4afb95380d1a92fddc2e2e31110d6e065c23036f

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

4afb953A few fixes for GLPK update to 4.55.

comment:75 Changed 5 years ago by jdemeyer

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

* zlib

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

comment:76 Changed 5 years ago by git

  • Commit changed from 4afb95380d1a92fddc2e2e31110d6e065c23036f to b3bf9531915bbd58e5dfd9513a5716596e268c02

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

b3bf953Refrain autotools from regenerating its files when configuring GLPK.

comment:77 Changed 5 years ago by jpflori

  • Status changed from needs_work to needs_review

comment:78 Changed 5 years ago by git

  • Commit changed from b3bf9531915bbd58e5dfd9513a5716596e268c02 to 2776a6822d914851de49da763ad3545e436ea7ef

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

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

comment:79 Changed 5 years ago by jpflori

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

comment:80 Changed 5 years ago by jpflori

  • Status changed from needs_review to needs_work
  • Summary changed from Update GLPK to 4.55. to Update GLPK to 4.55

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

comment:81 Changed 5 years ago by git

  • Commit changed from 2776a6822d914851de49da763ad3545e436ea7ef to 468a7d82271c50faf8ae45c60ffa2e1fb1c54cfc

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

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

comment:82 Changed 5 years ago by git

  • Commit changed from 468a7d82271c50faf8ae45c60ffa2e1fb1c54cfc to 8b77569ffeb481a541358c576244d0b91b4e5ad4

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

8b77569Fix GLPK tweak for Cygwin.

comment:83 Changed 5 years ago by git

  • Commit changed from 8b77569ffeb481a541358c576244d0b91b4e5ad4 to 584cbd68931d7a0a1a6315dde1a98c5011a431d7

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

584cbd6Fix stupid typo in previous commit for GLPK on Cygwin.

comment:84 Changed 5 years ago by jpflori

  • Status changed from needs_work to needs_review

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.

comment:85 Changed 5 years ago by jpflori

  • Cc tscrim added

comment:86 Changed 5 years ago by vbraun

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

comment:87 Changed 5 years ago by git

  • Commit changed from 584cbd68931d7a0a1a6315dde1a98c5011a431d7 to 9ecce275cf6f9455e2b732c84518fe293aa2bdea

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

c333b09Merge remote-tracking branch 'trac/develop' into ticket/12703
9ecce27Modify GLPK test involving numerical noise.

comment:88 Changed 5 years ago by jpflori

Tests modified.

comment:89 Changed 5 years ago by vbraun

  • Reviewers changed from Nathann Cohen to Nathann Cohen, Volker Braun
  • Status changed from needs_review to positive_review

comment:90 Changed 5 years ago by vbraun

  • Status changed from positive_review to needs_work
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
----------------------------------------------------------------------

comment:91 Changed 5 years ago by vbraun

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

comment:92 Changed 5 years ago by git

  • Commit changed from 9ecce275cf6f9455e2b732c84518fe293aa2bdea to 827eaa3f611a7ea8b4e9ee2a1506d6eff3a0ef84

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

827eaa3Further numerical noise after GLPK updated.

comment:93 Changed 5 years ago by jpflori

  • Status changed from needs_work to positive_review

comment:94 Changed 5 years ago by vbraun

  • Branch changed from u/jpflori/ticket/12703 to 827eaa3f611a7ea8b4e9ee2a1506d6eff3a0ef84
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:95 in reply to: ↑ description ; follow-up: Changed 4 years ago by jdemeyer

  • Commit 827eaa3f611a7ea8b4e9ee2a1506d6eff3a0ef84 deleted

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.

comment:96 in reply to: ↑ 95 Changed 4 years ago by 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.

comment:97 Changed 4 years ago by jdemeyer

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

Note: See TracTickets for help on using tickets.