Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#12725 closed defect (fixed)

termcap: symlink libtermcap.a to libncurses.a

Reported by: jdemeyer Owned by: tbd
Priority: minor Milestone: sage-5.7
Component: packages: standard Keywords:
Cc: jpflori Merged in: sage-5.7.beta3
Authors: Jeroen Demeyer Reviewers: Volker Braun
Report Upstream: Reported upstream. No feedback yet. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jdemeyer)

The install scripts for PARI and Python automatically link with -lncurses if /usr/lib/libncurses.so exists, even though the mere existence of that file doesn't guarantee that it actually can be linked. This can happen in particular when "cross-compiling" a 32-bit Sage on a 64-bit operating system.

The build of the readline interface of PARI and Python might therefore fail for no good reason. A solution is to symlink Sage's libtermcap.a to libncurses.a if needed, such that -lncurses will always succeed.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/termcap-1.3.1.p3.spkg

Reported upstream to Python: http://bugs.python.org/issue15182

For PARI, this seems to be fixed in PARI-2.6.0 (but I haven't checked well).

Attachments (1)

termcap-1.3.1.p3.diff (2.3 KB) - added by jdemeyer 9 years ago.
Diff for the termcap spkg, for review only

Download all attachments as: .zip

Change History (24)

comment:1 Changed 9 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Description modified (diff)

comment:2 Changed 9 years ago by jdemeyer

  • Description modified (diff)

comment:3 follow-up: Changed 9 years ago by tdickey

The usual way to address the problem is to install the corresponding development package (for ncurses). Overwriting the shared library will break various programs that are linked against the existing library.

comment:4 in reply to: ↑ 3 Changed 9 years ago by jdemeyer

Replying to tdickey:

Overwriting the shared library will break various programs that are linked against the existing library.

I'm only talking about the static library archive (libncurses.a). This cannot break existing programs.

comment:5 Changed 9 years ago by tdickey

But that would break builds of other applications which used the static library. Also, applications using the bundled termcap library would behave differently from those which use the ncurses library (unless Sage happened to update its termcap source file - last I recalled it was more than ten years out of date).

comment:6 Changed 9 years ago by jdemeyer

Okay, a new proposal: we try to link a test program with -lncurses and only if that fails, we do the copying.

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

That's an improvement, but if the copy happened to be put in a different location than the ncurses development package, it would still be a problem.

comment:8 in reply to: ↑ 7 Changed 9 years ago by jdemeyer

Replying to tdickey:

That's an improvement, but if the copy happened to be put in a different location than the ncurses development package, it would still be a problem.

??? Please explain what you mean. The copy would be put in $SAGE_ROOT/local/lib.

comment:9 Changed 9 years ago by tdickey

I see - at the end of the patch. The discussion above did not make that clear.

Changed 9 years ago by jdemeyer

Diff for the termcap spkg, for review only

comment:10 Changed 9 years ago by jdemeyer

  • Priority changed from major to minor
  • Status changed from new to needs_review

The new spkg is more clever: it only makes the symbolic link for libncurses.a if linking against -lncurses doesn't work.

Needs review.

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

@tdickey: could you review this spkg please?

comment:12 follow-up: Changed 9 years ago by leif

We should get rid of the termcap spkg anyway, really.

Besides that, the errors mentioned in the description should certainly get fixed (or at least reported) upstream.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 9 years ago by jdemeyer

Replying to leif:

Besides that, the errors mentioned in the description should certainly get fixed (or at least reported) upstream.

I don't think upstream still exists, actually.

comment:14 Changed 9 years ago by jdemeyer

  • Description modified (diff)
  • Summary changed from termcap: copy libtermcap.a to libncurses.a to termcap: symlink libtermcap.a to libncurses.a

comment:15 Changed 9 years ago by jdemeyer

  • Description modified (diff)
  • Report Upstream changed from N/A to Reported upstream. No feedback yet.

comment:16 in reply to: ↑ 13 Changed 9 years ago by tdickey

Replying to jdemeyer:

Replying to leif:

Besides that, the errors mentioned in the description should certainly get fixed (or at least reported) upstream.

I don't think upstream still exists, actually.

Which upstream are you referring to?

comment:17 in reply to: ↑ 11 ; follow-up: Changed 9 years ago by tdickey

Replying to jdemeyer:

@tdickey: could you review this spkg please?

Generically ok (given the explanation that it would only be used in a build-tree, not updating the system area).

However, 1.3.1.p3 is dated, and its termcap.src file is a nuisance due to the large number of differences versus ncurses. I've noticed that Redhat's equivalent package for termcap uses the termcap.src file which I generate from ncurses. See http://invisible-island.net/datafiles/current/termcap.src.gz for comparison.

Last edited 9 years ago by tdickey (previous) (diff)

comment:18 in reply to: ↑ 17 Changed 9 years ago by jdemeyer

Replying to tdickey:

Replying to jdemeyer:

@tdickey: could you review this spkg please?

Generically ok (given the explanation that it would only be used in a build-tree, not updating the system area).

However, 1.3.1.p3 is dated, and its termcap.src file is a nuisance due to the large number of differences versus ncurses.

Perhaps, but that's not the subject of this ticket.

comment:19 follow-up: Changed 8 years ago by jpflori

  • Cc jpflori added

Wouldn't a proper solution be to fix Pyton rather than hacking around?

comment:20 in reply to: ↑ 19 Changed 8 years ago by jdemeyer

Replying to jpflori:

Wouldn't a proper solution be to fix Pyton rather than hacking around?

Sure, but that's not a realistic solution I'm afraid. It would require some redesign of the Python build system.

comment:21 Changed 8 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

ugly workaround, but then it should never happen on a sensible install...

comment:22 Changed 8 years ago by jdemeyer

  • Merged in set to sage-5.7.beta3
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:23 Changed 8 years ago by vbraun

This breaks readline in Python, see #14405 for details.

Note: See TracTickets for help on using tickets.