termcap: symlink libtermcap.a to libncurses.a

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

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

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

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

[jdemeyer]

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

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

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

[tdickey]

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

[jdemeyer]

Diff for the termcap spkg, for review only

[jdemeyer]

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

Needs review.

[jdemeyer]

@tdickey: could you review this spkg please?

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

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

[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?

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

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

[jpflori]

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

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

[vbraun]

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

[vbraun]

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