#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, GitHub, GitLab) | Commit: | |
Dependencies: | Stopgaps: |
Description (last modified by )
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)
Change History (99)
comment:1 Changed 10 years ago by
- Cc ncohen SimonKing added
- Description modified (diff)
- Keywords upgrade update added
- Status changed from new to needs_review
comment:2 Changed 10 years ago by
comment:3 Changed 10 years ago by
- 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 10 years ago by
- Reviewers set to Nathann Cohen
comment:5 follow-up: ↓ 6 Changed 10 years ago by
Well, this one works on my computer, and all tests pass in graph/ and numerical/ folders :-)
Nathann
Changed 10 years ago by
Diff between the previous spkg in Sage and my new p1 spkg. For reference / review only.
comment:6 in reply to: ↑ 5 Changed 10 years ago by
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 10 years ago by
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: ↓ 9 ↓ 10 ↓ 12 Changed 10 years ago by
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 10 years ago by
Replying to leif:
beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded
gcc
org++
(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: ↓ 11 Changed 10 years ago by
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
org++
(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 yourPATH
, 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 10 years ago by
Replying to SimonKing:
What I would like to see is a syntax like
$ make cloog_ppl libelf gcc allwhich 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: ↓ 14 Changed 10 years ago by
Replying to leif:
beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded
gcc
org++
(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 10 years ago by
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: ↓ 15 Changed 10 years ago by
Replying to SimonKing:
Replying to leif:
beta9 would probably be a better starting point, since it merges three spkgs fixing hardcoded
gcc
org++
(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: ↓ 17 Changed 10 years ago by
Replying to leif:
Well, if you happen to have the desired
gcc
/g++
[first] in yourPATH
(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 whatevercommand -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 10 years ago by
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 10 years ago by
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: ↓ 19 Changed 10 years ago by
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 10 years ago by
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: ↓ 21 Changed 10 years ago by
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: ↓ 22 Changed 10 years ago by
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: ↓ 23 Changed 10 years ago by
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 10 years ago by
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 usingCPPFLAGS
.
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 10 years ago by
See #12741: I found a similar problem with R.
comment:25 Changed 9 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:26 Changed 9 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:27 Changed 8 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:28 Changed 8 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:29 Changed 8 years ago by
Upstream is now at 4.55.
comment:30 Changed 8 years ago by
For GLPK included zlib, see Fedora's choice: http://pkgs.fedoraproject.org/cgit/glpk.git/commit/?id=f00815ed66d7e71c48afba9cdcb20575a49c38bd
comment:31 follow-up: ↓ 39 Changed 8 years ago by
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 8 years ago by
(That is when trying to build with "CFLAGS=-flto ./sage -flto glpk" with glpk 4.55.)
comment:33 Changed 8 years ago by
I attached the spkg-src script used...
Changed 8 years ago by
comment:34 Changed 8 years ago by
Ok, using CC=gcc -flto
works...
comment:35 Changed 8 years ago by
But it seems GLPK does not care about CC.
comment:36 Changed 8 years ago by
Or I just don't know enough about LTO to understand anything.
comment:37 Changed 8 years ago by
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 8 years ago by
@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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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: ↓ 45 Changed 8 years ago by
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: ↓ 47 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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: ↓ 48 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
Ok, it seems to be a similar issue as in:
Passing CFLAGS="-flto -ffat-lto-objects" works fine...
comment:52 Changed 8 years ago by
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 8 years ago by
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: ↓ 55 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
- 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.
comment:57 follow-up: ↓ 58 Changed 8 years ago by
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: ↓ 62 Changed 8 years ago by
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: ↓ 70 Changed 8 years ago by
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 8 years ago by
- Status changed from needs_review to needs_work
Also, CFALGS
surely is a typo?
comment:61 Changed 8 years ago by
If you add
# Exit on error set -e
then remove all other error checking :-)
comment:62 in reply to: ↑ 58 Changed 8 years ago by
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: ↓ 65 Changed 8 years ago by
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: ↓ 66 Changed 8 years ago by
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
?
comment:65 in reply to: ↑ 63 Changed 8 years ago by
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 causeconfigure.ac
to have a newer timestamp thanconfigure
.
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: ↓ 69 Changed 8 years ago by
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: ↓ 68 Changed 8 years ago by
What does the "Reported upstream. Developers acknowledge bug." refer to and where is the upstream report?
comment:68 in reply to: ↑ 67 Changed 8 years ago by
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 8 years ago by
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 ofGMP
included in a bunch of packages.
Also note that we ship a vanilla tarball.
comment:70 in reply to: ↑ 59 Changed 8 years ago by
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 itand
* 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: ↓ 72 Changed 8 years ago by
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: ↓ 73 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
- Commit changed from 758b53a7487cb405286ad009caaab733842f0f8e to 4afb95380d1a92fddc2e2e31110d6e065c23036f
Branch pushed to git repo; I updated commit sha1. New commits:
4afb953 | A few fixes for GLPK update to 4.55.
|
comment:75 Changed 8 years ago by
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 8 years ago by
- Commit changed from 4afb95380d1a92fddc2e2e31110d6e065c23036f to b3bf9531915bbd58e5dfd9513a5716596e268c02
Branch pushed to git repo; I updated commit sha1. New commits:
b3bf953 | Refrain autotools from regenerating its files when configuring GLPK.
|
comment:77 Changed 8 years ago by
- Status changed from needs_work to needs_review
comment:78 Changed 8 years ago by
- Commit changed from b3bf9531915bbd58e5dfd9513a5716596e268c02 to 2776a6822d914851de49da763ad3545e436ea7ef
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.
|
comment:79 Changed 8 years ago by
FYI, the cygwin shared lib stuff should go upstream in one form or another. See:
comment:80 Changed 8 years ago by
- 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 8 years ago by
- Commit changed from 2776a6822d914851de49da763ad3545e436ea7ef to 468a7d82271c50faf8ae45c60ffa2e1fb1c54cfc
comment:82 Changed 8 years ago by
- Commit changed from 468a7d82271c50faf8ae45c60ffa2e1fb1c54cfc to 8b77569ffeb481a541358c576244d0b91b4e5ad4
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
8b77569 | Fix GLPK tweak for Cygwin.
|
comment:83 Changed 8 years ago by
- Commit changed from 8b77569ffeb481a541358c576244d0b91b4e5ad4 to 584cbd68931d7a0a1a6315dde1a98c5011a431d7
Branch pushed to git repo; I updated commit sha1. New commits:
584cbd6 | Fix stupid typo in previous commit for GLPK on Cygwin.
|
comment:84 Changed 8 years ago by
- 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 8 years ago by
- Cc tscrim added
comment:86 Changed 8 years ago by
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 8 years ago by
- Commit changed from 584cbd68931d7a0a1a6315dde1a98c5011a431d7 to 9ecce275cf6f9455e2b732c84518fe293aa2bdea
comment:88 Changed 8 years ago by
Tests modified.
comment:89 Changed 8 years ago by
- Reviewers changed from Nathann Cohen to Nathann Cohen, Volker Braun
- Status changed from needs_review to positive_review
comment:90 Changed 8 years ago by
- 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 8 years ago by
Apart from that one the buildbot didn't find any other failures.
comment:92 Changed 8 years ago by
- Commit changed from 9ecce275cf6f9455e2b732c84518fe293aa2bdea to 827eaa3f611a7ea8b4e9ee2a1506d6eff3a0ef84
Branch pushed to git repo; I updated commit sha1. New commits:
827eaa3 | Further numerical noise after GLPK updated.
|
comment:93 Changed 8 years ago by
- Status changed from needs_work to positive_review
comment:94 Changed 8 years ago by
- 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: ↓ 96 Changed 7 years ago by
- 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 7 years ago by
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 7 years ago by
I just don't feel motivated to maintained a patch which isn't actually needed.
To also motivate the upgrade:
GLPK 4.47 (release date: Sep 09, 2011)
GLPK 4.46 (release date: Aug 09, 2011)
GLPK 4.45 (release date: Dec 05, 2010)