[GRASSLIST:1265] Re: readline problem and fix

[Jack Varga]

Glynn,

Thanks for the explanation.  I'm reposting to the list as I'm sure 
someone can benefit from this down the road.

Best regards,

Jack Varga

Glynn Clements wrote:

>Jack Varga wrote:
>
>  
>
>>>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).
>>>
>>>      
>>>
>>Until they do, would it be advantageous to add links for each of these 
>>shared libraries?
>>    
>>
>
>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.
>
>  
>
>>Relatedly, don't termcap and terminfo libraries, for 
>>all practical purposes, provide the same functionality?
>>    
>>
>
>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.
>
>  
>
>>For that 
>>matter, isn't curses decprecated by ncurses (new curses)?
>>    
>>
>
>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.
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20030916/1443aa4c/attachment.html