Opened 8 years ago

Last modified 4 years ago

#12703 closed defect

Update GLPK to 4.55. — at Version 56

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
Report Upstream: Reported upstream. Developers acknowledge bug. Work issues:
Branch: u/jpflori/ticket/12703 (Commits) Commit: 758b53a7487cb405286ad009caaab733842f0f8e
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:

Change History (58)

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.
Note: See TracTickets for help on using tickets.