search

sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.39k stars 473 forks source link

Update GLPK to 4.55 #12703

Closed 83660e46-0051-498b-a8c1-f7a7bd232b5a closed 9 years ago

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

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:

Upstream: Reported upstream. Developers acknowledge bug.

CC: @nathanncohen @simon-king-jena @tscrim

Component: packages: standard

Keywords: link time optimization nm glpsol spkg upgrade update

Author: Leif Leonhardy, Jean-Pierre Flori

Branch: 827eaa3

Reviewer: Nathann Cohen, Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/12703

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

Author: Leif Leonhardy

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

Changed keywords from link time optimization nm glpsol spkg to link time optimization nm glpsol spkg upgrade update

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

Description changed:

--- 
+++ 
@@ -6,3 +6,23 @@

 I have an spkg with updated autogenerated files which also upgrades GLPK within Sage to the latest stable version, 4.47.

+---
+
+**New spkg:** [http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p0.spkg](http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p0.spkg)
+
+**md5sum:** `820b1169551ca7da973a09a672da1560  glpk-4.47.p0.spkg`
+
+### glpk-4.47.p0 (Leif Leonhardy, March 19th 2012)
+* #12703: Make GLPK work with LTO (`gcc -flto ...`).
+  This just involves updating the lib- and autotools files,
+  but thereby upgrading to the latest version (4.47) shouldn't
+  hurt either.
+  Note that the `src/` directory now isn't vanilla, since upstream
+  hasn't yet fixed the bug (i.e., updated these files).
+  The "real" source files in contrast of course *are*.
+  See "Special Update/Build Instructions" above on how to update
+  the files of a fresh upstream tarball if necessary.
+* Cleaned up `spkg-install` and `spkg-check` (and this file ;-)
+* Running the test suite now uses `$MAKE` instead of `make` as well.
+* `CPPFLAGS` and `LDFLAGS` no longer get overwritten in `spkg-install`.
+
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:2

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@gmail.com> 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@gmx.de>.

GLPK 4.45 (release date: Dec 05, 2010)

    This is a bug-fix release.

    Several bugs/typos were fixed. Thanks to
    Xypron <xypron.glpk@gmx.de>,
    Robbie Morrison <robbie@actrix.co.nz>, and
    Ali Baharev <ali.baharev@gmail.com> 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
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

Description changed:

--- 
+++ 
@@ -8,9 +8,15 @@

 ---

-**New spkg:** [http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p0.spkg](http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p0.spkg)
+**New spkg:** [http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p1.spkg](http://boxen.math.washington.edu/home/leif/Sage/spkgs/glpk-4.47.p1.spkg)

-**md5sum:** `820b1169551ca7da973a09a672da1560  glpk-4.47.p0.spkg`
+**md5sum:** `090ee5d398582db531b27e49deab6749  glpk-4.47.p1.spkg`
+
+
+### glpk-4.47.p1 (Leif Leonhardy, March 22nd 2012)
+* #12703: Make GLPK work with LTO (`gcc -flto ...`).
+  Export CPPFLAGS, since `sage-env` currently *doesn't*.
+

 ### glpk-4.47.p0 (Leif Leonhardy, March 19th 2012)
 * #12703: Make GLPK work with LTO (`gcc -flto ...`).
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:3

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

Reviewer: Nathann Cohen

6bdad4c1-1e26-4f2f-a442-a01a2292c181 commented 12 years ago
comment:5

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

Nathann

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:6

Attachment: glpk-4.44.p0-4.47.p1.diff.gz

Replying to @nathanncohen:

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

simon-king-jena commented 12 years ago
comment:7

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:8

Slightly off the ticket's topic:

Replying to @simon-king-jena:

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:9

Replying to @nexttime:

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.

simon-king-jena commented 12 years ago
comment:10

Replying to @nexttime:

Slightly off the ticket's topic:

Replying to @simon-king-jena:

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.

simon-king-jena commented 12 years ago
comment:11

Replying to @simon-king-jena:

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!

simon-king-jena commented 12 years ago
comment:12

Replying to @nexttime:

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.

simon-king-jena commented 12 years ago
comment:13

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:14

Replying to @simon-king-jena:

Replying to @nexttime:

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.

simon-king-jena commented 12 years ago
comment:15

Replying to @nexttime:

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?

simon-king-jena commented 12 years ago
comment:16

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:17

Replying to @simon-king-jena:

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.

simon-king-jena commented 12 years ago
comment:18

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!

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:19

Replying to @simon-king-jena:

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

simon-king-jena commented 12 years ago
comment:20

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:21

Replying to @simon-king-jena:

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?

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 12 years ago
comment:22

Replying to @nexttime:

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.

simon-king-jena commented 12 years ago
comment:23

Replying to @nexttime:

Replying to @nexttime:

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.

simon-king-jena commented 12 years ago
comment:24

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

jpflori commented 9 years ago
comment:29

Upstream is now at 4.55.

jpflori commented 9 years ago
comment:30

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

jpflori commented 9 years ago
comment:31

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

jpflori commented 9 years ago
comment:32

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

jpflori commented 9 years ago
comment:33

I attached the spkg-src script used...

jpflori commented 9 years ago

Attachment: spkg-src.gz

jpflori commented 9 years ago
comment:34

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

jpflori commented 9 years ago
comment:35

But it seems GLPK does not care about CC.

jpflori commented 9 years ago
comment:36

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

jpflori commented 9 years ago
comment:37

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

jpflori commented 9 years ago
comment:38

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 9 years ago
comment:39

Replying to @jpflori:

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

Sorry for the delay...

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

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

That pretty much sounds like the original failure.

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

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

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

jpflori commented 9 years ago
comment:40

Everything I used was quite recent:

jpflori commented 9 years ago
comment:41

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 9 years ago
comment:42

Ahem, from SPKG.txt:

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

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

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

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

(I used m4 1.4.16, libtool 2.4.2, autoconf 2.68 and automake 1.11.3 
to update the files for the glpk-4.47.p0 spkg.) -leif (03/2012) 
jpflori commented 9 years ago
comment:43

I don't get your post...

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

jpflori commented 9 years ago
comment:44

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 9 years ago
comment:45

Replying to @jpflori:

I don't get your post...

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

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

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

Could you post the exact error you got?

jpflori commented 9 years ago
comment:46

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:

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'
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 9 years ago
comment:47

Replying to @jpflori:

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

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

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

They should.

jpflori commented 9 years ago
comment:48

Replying to @nexttime:

Replying to @jpflori:

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

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

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

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

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