#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 )
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)
Change History (24)
comment:1 Changed 9 years ago by
- Description modified (diff)
comment:2 Changed 9 years ago by
- Description modified (diff)
comment:3 follow-up: ↓ 4 Changed 9 years ago by
comment:4 in reply to: ↑ 3 Changed 9 years ago by
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
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
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: ↓ 8 Changed 9 years ago by
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
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
I see - at the end of the patch. The discussion above did not make that clear.
comment:10 Changed 9 years ago by
- 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: ↓ 17 Changed 9 years ago by
@tdickey: could you review this spkg please?
comment:12 follow-up: ↓ 13 Changed 9 years ago by
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: ↓ 16 Changed 9 years ago by
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
- 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
- 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
comment:17 in reply to: ↑ 11 ; follow-up: ↓ 18 Changed 9 years ago by
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.
comment:18 in reply to: ↑ 17 Changed 9 years ago by
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: ↓ 20 Changed 8 years ago by
- 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
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
- 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
- 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
This breaks readline in Python, see #14405 for details.
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.