Opened 8 years ago

Closed 6 years ago

#11391 closed defect (duplicate)

ppl library problems on Arch Linux, OpenSuse: _ZN23Parma_Polyhedra_Library13have_sse_unitE

Reported by: gostrc Owned by: GeorgSWeber
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: packages: standard Keywords:
Cc: aginiewicz Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

I am using the sage 4.7 release. I'm trying to package sage for archlinux, and the x86_64 version compiled fine. But the i686 version of the package failed with the error described here: http://groups.google.com/group/sage-devel/browse_thread/thread/84b2f4d94d50e735

The complete install.log can be found here: http://pkgbuild.com/~td123/install.log.gz

The relevant install.log portion (the error message) is: http://pastie.org/pastes/1980914/text

Attachments (2)

sage.output.i686.gz (381.3 KB) - added by gostrc 7 years ago.
sage.output.i686.workaround.gz (1.7 MB) - added by gostrc 7 years ago.

Change History (24)

comment:1 Changed 8 years ago by gostrc

A temporary fix for me before running `make' was to do the following:

mkdir -p spkg/installed touch spkg/installed/ppl-0.11.2

comment:2 Changed 7 years ago by gostrc

It seems that with sage 4.8, this workaround doesn't work anymore. I attached the output I get when building on i686 without the above workaround. (sage.output.i686)

Changed 7 years ago by gostrc

comment:3 Changed 7 years ago by gostrc

This is what I get when trying to compile with the workaround:

mkdir -p spkg/installed
touch spkg/installed/ppl-0.11.2.p0

Output:

Installing c_lib
scons: `install' is up to date.
Updating Cython code....
Executing 0 commands (using 0 threads)
Time to execute 0 commands: 0.0769848823547 seconds
Finished compiling Cython code (time = 0.446054935455 seconds)
running install
running build
running build_py
running build_ext
building 'sage.libs.ppl' extension
Executing 1 command (using 1 thread)
error: /build/src/sage-4.8/local/include/ppl.hh: No such file or directory
sage: There was an error installing modified sage library code.

make: *** [build] Error 1

attached the full build output as sage.output.i686.workaround.gz

Changed 7 years ago by gostrc

comment:4 Changed 7 years ago by gostrc

just rebuilt 4.7.2 and it works, so this was introduced in 4.8 for sure.

comment:5 Changed 7 years ago by GeorgSWeber

  • Summary changed from error building sage 4.7: undefined symbol: _ZN23Parma_Polyhedra_Library13have_sse_unitE to ppl library problems on Arch Linux, OpenSuse: _ZN23Parma_Polyhedra_Library13have_sse_unitE

I think that the following post (for OpenSuse 12.1) mentions exactly the same underlying problem:

http://groups.google.com/group/sage-devel/browse_thread/thread/a7017c8f3b0a16c0

It seems that from Sage 4.8 on, the ppl (Parma Polyhedra Library) got interfaced by the Sage core. So the "workaround" to not build the ppl spkg at all ("touch spkg/installed/ppl-0.11.2.p0") simply won't work for Sage 4.8 and later (since the respective headers are needed)!

As long as the ppl library included in Sage and the ppl library of the host OS do not differ too much (they seem to be "close enough" right now in the known cases Arch Linx, OpenSuse 11.4 - 12.1), one probably could use a different workaround:

a) *do* build the ppl spkg (in order to get the header files in place)

b) after that (just waiting for the "breakage" might be sufficient), replace the library binary ("libppl.so.9.0.0" or so) under $SAGE_LOCAL/lib/ with a symlink to the host OS'es libppl.

For some "correct" solution, one would either have to update the ppl spkg to install a newer version of ppl, to match the one of the host OS(es) --- somewhat a "moving target" (we might end up with having to provide several different versions of ppl in the spkg).

Or provide the technical foundation so that the libraries brought with Sage do not (i.e. no longer) interfere with libraries on the host OS (the ticket #10572 describes one of several ways to do so).

Cheers,

Georg

comment:6 Changed 7 years ago by aginiewicz

  • Cc aginiewicz added

I don't know if this is a known thing, but one of Arch Linux users (going by name Snowball on AUR, the Arch Linux User Repository) posted a working solution for ppl problem on i686, and it is quite a simple change to ppl spkg:

sed -i 's/--enable-interfaces=c++/--enable-interfaces="c++ c"/' ppl-0.11.2.p0/spkg-install

I tested this in i686 VM of Arch Linux and can confirm that with this change to ppl spkg it works (right now Sage 4.8 still builds, but it got past pycrypto where it failed before). Unfortunately right now I don't have time to post an updated spkg, but I decided to let others know about it anyway.

comment:7 Changed 7 years ago by aginiewicz

  • Status changed from new to needs_review

I finished building 4.8 without any issue on current Arch Linux i686, also found some time so I decided to refresh my knowledge and package new ppl. The spkg with mentioned fix is here: https://github.com/downloads/aginiewicz/spkgs/ppl-0.11.2.p2.spkg - I hope I still remember how to package for Sage.

comment:8 Changed 7 years ago by kini

  • Component changed from build to packages

comment:9 follow-up: Changed 7 years ago by jdemeyer

This is a duplicate of #12672 (which has the same solution for a different problem).

comment:10 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by SimonKing

Replying to jdemeyer:

This is a duplicate of #12672 (which has the same solution for a different problem).

I think it is not a duplicate. #12672 is about building the C interface of PPL, which is currently not done. Solving build problems on some platforms is an orthogonal problem, IMHO.

comment:11 in reply to: ↑ 10 Changed 7 years ago by jdemeyer

Replying to SimonKing:

Replying to jdemeyer:

This is a duplicate of #12672 (which has the same solution for a different problem).

I think it is not a duplicate. #12672 is about building the C interface of PPL, which is currently not done. Solving build problems on some platforms is an orthogonal problem, IMHO.

As I said, ticket #12672 has the same solution for a different problem.

comment:12 follow-up: Changed 7 years ago by SimonKing

Aha, now I see the comment of aginiewicz: "a working solution for ppl problem on i686, and it is quite a simple change to ppl spkg:

sed -i 's/--enable-interfaces=c++/--enable-interfaces="c++ c"/' ppl-0.11.2.p0/spkg-install

So, you are right, it is about building interfaces, in order to achieve something else.

Since #12672 has an spkg (even though it fails on OS X because of missing m4): What shall we do? Close this ticket as a duplicate? Leave both open? Do we need an m4 spkg?

comment:13 in reply to: ↑ 12 Changed 7 years ago by jdemeyer

Replying to SimonKing:

Do we need an m4 spkg?

I think we should have an m4 spkg, but most people disagree (there was a mailing list post on this).

comment:14 Changed 7 years ago by jdemeyer

Please fill in your real name as Author.

comment:15 Changed 7 years ago by aginiewicz

  • Authors set to Andrzej Giniewicz

comment:16 Changed 7 years ago by jdemeyer

Just got another report of this error on the mailing list. We really should fix this.

comment:17 follow-up: Changed 7 years ago by SimonKing

Would #12672 work, modulo providing an m4 spkg on OS X?

comment:18 Changed 7 years ago by aginiewicz

The difference between spkg in #12672 and spkg I posted in comment:7 (that contains fix used by Arch Linux package, i.e. is tested in production environment) is only "make install" vs "make install-strip", so I'd say yes - both spkgs fixes this and #12672 - but both would have issues with m4 on OS X.

comment:19 in reply to: ↑ 17 Changed 6 years ago by jdemeyer

Replying to SimonKing:

Would #12672 work, modulo providing an m4 spkg on OS X?

Absolutely.

Just got another report of this error on the mailing list. We really should fix this.

comment:20 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to needs_work

comment:21 Changed 6 years ago by jdemeyer

  • Authors Andrzej Giniewicz deleted
  • Milestone changed from sage-5.10 to sage-duplicate/invalid/wontfix
  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_work to positive_review

Fixed by #14232.

comment:22 Changed 6 years ago by jdemeyer

  • Resolution set to duplicate
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.