[illumos-Developer] 415 libreadline.so.5: symbol tgetent ... not found

Albert Lee trisk at opensolaris.org
Thu Jun 30 13:21:23 PDT 2011


On Thu, Jun 30, 2011 at 3:46 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
> On Thu, 2011-06-30 at 13:44 -0400, Gordon Ross wrote:
>> On Thu, Jun 30, 2011 at 11:34 AM, Garrett D'Amore <garrett at nexenta.com> wrote:
>> > Generally, it looks good.  Any reason we have to ship termcap.h though?
>> > Applications shouldn't be including this should they?  (Its not present
>> > on our existing system....)
>>
>> We don't have to ship it, but I think it's better to do so.  Here's why:
>>
>> Before this (proposed) work, we did not really have a libtermcap.
>> An application that needed the BSD-ish tget* etc functions had to
>> import all of libcurses, and the headers defining what you actually
>> import are curses.h and term.h.
>>
>> With the proposed filter library as libtermcap, it's actually possible
>> to import only the six BSD-ish tget* etc functions.  (And do that in a
>> way that does not drag in libcurses if you have another curses lib
>> providing those symbols).  So I think it's helpful to actually provide a
>> header defining that interface, and termcap.h is the traditional name
>> of the header to define that.
>>
>> The proposed termcap.h is just like the traditional BSD one, so I
>> don't expect it to cause surprises in applications.  As an example,
>> the readline code autoconfgure found and used it just fine.
>
> Ok, thanks for the explanation.  I am slightly (only slightly) concerned
> that some code might sense this header and assume BSD semantics, or
> choose BSD interfaces over SVR4 ones... is that a problem?
>
>        - Garrett
>>
>> Gordon
>>

The interfaces are also part of SUSv2 (but not later POSIX specs),
where they are accessible from term.h... should we support that?

The filter library looks excellent to me.

-Albert



More information about the Developer mailing list