<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<DEFANGED_meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Glynn, <br>
<br>
Thanks for the explanation. I'm reposting to the list as I'm sure
someone can benefit from this down the road.<br>
<br>
Best regards, <br>
<br>
Jack Varga<br>
<br>
Glynn Clements wrote:<br>
<blockquote type="cite"
cite="mid16231.49505.487565.409007@cerise.nosuchdomain.co.uk">
<pre wrap="">Jack Varga wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'd rather they just filed bug reports with their OS vendor until the vendor issues a version of readline with the correct dependency information (as is the case for e.g. RH6.2's readline).
</pre>
</blockquote>
<pre wrap="">Until they do, would it be advantageous to add links for each of these
shared libraries?
</pre>
</blockquote>
<pre wrap=""><!---->
We definitely don't want to link in more than one of them; on many
platforms, that in itself would cause an error. On platforms which
allow this, only one of them (typically either the first or last)
would actually be used. Also, if you specify a library which doesn't
exist, that will usually cause an error even if the library isn't
actually required.
</pre>
<blockquote type="cite">
<pre wrap="">Relatedly, don't termcap and terminfo libraries, for
all practical purposes, provide the same functionality?
</pre>
</blockquote>
<pre wrap=""><!---->
They provide the same essential functionality, i.e. they provide
functions which allow an application to determine whether the current
terminal type supports a particular feature and, if so, which codes
are used to activate it. However:
1. There are two different sets of functions: the original termcap API
(tgetstr etc) and the newer terminfo API (tigetstr etc).
2. There are two different database formats: the original termcap
format (a single text file, typically /etc/termcap) and the newer
terminfo format (a directory tree of binary files, with one file for
each terminal type).
To complicate matters, there is no guarantee that the choice of API
matches the choice of database; it's quite possible that a library
provides the termcap API but actually uses the terminfo database (a
common approach is to try terminfo first then termcap).
While the configure script can readily determine whether a library
provides the correct API, there is no practical way for it to
determine which database is used. Which is unfortunate, because the
choice of database may be important; it's quite possible that one
database is more complete and/or more accurate than the other.
</pre>
<blockquote type="cite">
<pre wrap="">For that
matter, isn't curses decprecated by ncurses (new curses)?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, although:
1. We make reasonable efforts to support legacy systems.
2. Of the libraries in question ([n]curses, termcap, tinfo), [n]curses
should be the last choice. The other two are much simpler, simply
providing an interface for querying the termcap/terminfo databases.
Curses is a higher-level library, and significantly more complex (and
hence more likely to introduce additional problems) than the other
two.
In summary: configure can easily go through a list of combinations,
such as:
-lreadline -ltinfo
-lreadline -ltermcap
-lreadline -lncurses
-lreadline -lcurses
determining whether each combination succeeds. The problem is that, if
more than one of the combinations works (and that's highly likely),
how to choose which combination to actually use. Because it may well
make a difference.
</pre>
</blockquote>
</body>
</html>