Mailing List Archive

Klaus-Juergen Wolf <kjwolf@online.de> wrote:
> (Python 1.5.2 on FreeBSD 3.2-RELEASE (i386))

> I found that (after having compiled Python with cursesmodule.c -
> testall.py succeeds) the following program gives a segmentation
> fault:

As it appears,

-*-
import curses

curses.initscr()
curses.endwin()
-*-

alone does exactly the same. I've tested it in debugging environment,
where it doesn't happen, and I've checked the cursesmodule code, and I
still have no idea why this happens. (Inconsistency? But where?)

Stack trace says that it happens when the first actual write call to
libtermcap takes place.

The problem occurs under Solaris in the same way, while Linux doesn't
seem to know anything of it.

Anyone got an idea?

cu
k.j.

kjwolf@online.de (Klaus-Juergen Wolf) writes:

> Klaus-Juergen Wolf <kjwolf@online.de> wrote:
> > (Python 1.5.2 on FreeBSD 3.2-RELEASE (i386))
>
> > I found that (after having compiled Python with cursesmodule.c -

Andrich's curses support is more complete, particularly suited for
x/openpg compliant curses. It turns to be very useful to replace it.

> > testall.py succeeds) the following program gives a segmentation
> > fault:
>
> As it appears,
>
> -*-
> import curses
>
> curses.initscr()
> curses.endwin()
> -*-
>
> alone does exactly the same. I've tested it in debugging environment,
> where it doesn't happen, and I've checked the cursesmodule code, and I
> still have no idea why this happens. (Inconsistency? But where?)
>
> Stack trace says that it happens when the first actual write call to
> libtermcap takes place.

So curses on that platform still needs to be linked to libtermcap?
>
> The problem occurs under Solaris in the same way, while Linux doesn't
> seem to know anything of it.

Using libtermcap on those systems? Linux usually uses terminfo which is
already burried in the ncurses stuff. Solaris might use sun curses.

Btw why is there no direct termcap support for python?
Perl has Term::Cap , which doesn't even require the termcap library,
just the termcap data file (e.g. /etc/termcap).
Would it be very hard to provide?

Klaus Schilling

Klaus-Juergen Wolf <kjwolf@online.de> wrote:
> -*-
> import curses

> curses.initscr()
> curses.endwin()
> -*-

> alone does exactly the same. I've tested it in debugging environment,
> where it doesn't happen, and I've checked the cursesmodule code, and I
> still have no idea why this happens. (Inconsistency? But where?)

I now have solved the problem.
It depends on when the executable is linked to libmytinfo, which only
takes place on platforms that don't know the terminfo database, like
BSD and Solaris; there are two competing declarations of tputs().

libmytinfo has to be linked before libtermcap.

(Hours of debugging went for such a laugh... oh no!)

cu
k.j.

kjwolf@online.de (Klaus-Juergen Wolf) writes:
> It depends on when the executable is linked to libmytinfo, which only
> takes place on platforms that don't know the terminfo database, like
> BSD and Solaris; there are two competing declarations of tputs().

Why doesn't Freebsd know the terminfo database? Can't the one that is
integrated into ncurses be used on FreeBSD?

Klaus Schilling

Klaus Schilling <Klaus.Schilling@home.ivm.de> wrote:
> kjwolf@online.de (Klaus-Juergen Wolf) writes:
>> It depends on when the executable is linked to libmytinfo, which only
>> takes place on platforms that don't know the terminfo database, like
>> BSD and Solaris; there are two competing declarations of tputs().

> Why doesn't Freebsd know the terminfo database? Can't the one that is
> integrated into ncurses be used on FreeBSD?

I've been told ncurses 4.2 is incorporated in the FreeBSD 3.1 - but that
may still just be a port...

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey

Klaus Schilling <Klaus.Schilling@home.ivm.de> wrote:
> kjwolf@online.de (Klaus-Juergen Wolf) writes:
>> It depends on when the executable is linked to libmytinfo, which only
>> takes place on platforms that don't know the terminfo database, like
>> BSD and Solaris; there are two competing declarations of tputs().

> Why doesn't Freebsd know the terminfo database? Can't the one that is
> integrated into ncurses be used on FreeBSD?

Some versions in the past still knew it, but, it seems, nowadays,
termcap is the only valid standard for declaring terminal interactions.
In fact, NCurses _is_ integrated into FreeBSD, the bridge between the
two systems is libmytinfo, it seems. mytinfo now declares tputs(),
which termcap also also declares, therefore, there is a small conflict,
if you don't link them libraries in the correct order.

You could, anyway, install another NCurses "on-the-head" of the old
one. But that is Linux behavior, we won't do that.

cu
k.j.


--
Support Julia Hill - save the Redwood trees: http://www.lunatree.org/

Klaus Schilling <Klaus.Schilling@home.ivm.de> wrote:
>> Klaus-Juergen Wolf <kjwolf@online.de> wrote:
>> > (Python 1.5.2 on FreeBSD 3.2-RELEASE (i386))
>>
>> > I found that (after having compiled Python with cursesmodule.c -

> Andrich's curses support is more complete, particularly suited for
> x/openpg compliant curses. It turns to be very useful to replace it.

There are more Curses' and NCurses' in the world than I have fingers
and toes. You can easily write a Curses module that makes _you_ happy.
And the rest of the world... Why, do you think, do Oliver Andrich's
approaches have a 'b' in the version number? It's simple: they won't
work everywhere, here, for instance.

cu
k.j.

--
Support Julia Hill - save the Redwood trees: http://www.lunatree.org/

T.E.Dickey <dickey@shell.clark.net> wrote:
>>> It depends on when the executable is linked to libmytinfo, which only
>>> takes place on platforms that don't know the terminfo database, like
>>> BSD and Solaris; there are two competing declarations of tputs().

>> Why doesn't Freebsd know the terminfo database? Can't the one that is
>> integrated into ncurses be used on FreeBSD?

> I've been told ncurses 4.2 is incorporated in the FreeBSD 3.1 - but that
> may still just be a port...

Yes, there is such a port. Do you think, one could release code that
works on several machines, while some of them must install a special
program first?

cu
k.j.

PS: It wouldn't have worked anyway.

--
Support Julia Hill - save the Redwood trees: http://www.lunatree.org/

T.E.Dickey <dickey@shell.clark.net> wrote:
>>> It depends on when the executable is linked to libmytinfo, which only
>>> takes place on platforms that don't know the terminfo database, like
>>> BSD and Solaris; there are two competing declarations of tputs().

>> Why doesn't Freebsd know the terminfo database? Can't the one that is
>> integrated into ncurses be used on FreeBSD?

> I've been told ncurses 4.2 is incorporated in the FreeBSD 3.1 - but that
> may still just be a port...

Yes, there is such a port. Do you think, one could release code that
works on several machines, while some of them must install a special
program first?

In the top priority, Python should work. When you compile it, it should
work. When you decide to link libraries you have, it should work. When
you release code for Python, it *must* work.

Therefore, there are some modules that base on old, long forgotten
states, but still, some machines work with these, and only with these.

Curses now is a very old UI, very old, it was old when I first learned
it in the beginning of the 80's. Most people have forgotten that there
was a Curses before NCurses came up. cursesmodule now, it bases on
Curses with NCurses extensions. It is not acceptable to release a
cursesmodule that wouldn't work on all those platforms it formerly
worked on. If you intend that, you'll have to give it a new name.
Furthermore, you can't say, to make cursesmodule work, you have got to
download another one, it's beta, but maybe, it works on your desolated
site. But that's no solution. That's a cramp.

Anyway, that wouldn't have helped in my case, I think, since the name
conflict would have still existed - libtermcap would have been linked
before, since libreadline demands it, and, I'm afraid, since ncurses
originally defines tputs(), it would also been mis-linked. I don't
really know, I guess. I'm not so familiar with the dynamic linking
rules under ELF/BSD.

cu
k.j.


--
Support Julia Hill - save the Redwood trees: http://www.lunatree.org/

Klaus-Juergen Wolf <kjwolf@online.de> wrote:
> > Why doesn't Freebsd know the terminfo database? Can't the one that is
> > integrated into ncurses be used on FreeBSD?

> Some versions in the past still knew it, but, it seems, nowadays,
> termcap is the only valid standard for declaring terminal interactions.
> In fact, NCurses _is_ integrated into FreeBSD, the bridge between the
> two systems is libmytinfo, it seems. mytinfo now declares tputs(),
> which termcap also also declares, therefore, there is a small conflict,
> if you don't link them libraries in the correct order.

no. mytinfo is a rather old/nonstandard interface for terminfo (my copy of
FreeBSD comes with no documentation for it ;-), which is used to support an
old (read: obsolete & buggy) version of ncurses.

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey

Klaus-Juergen Wolf <kjwolf@online.de> wrote:
> T.E.Dickey <dickey@shell.clark.net> wrote:
> >>> It depends on when the executable is linked to libmytinfo, which only
> >>> takes place on platforms that don't know the terminfo database, like
> >>> BSD and Solaris; there are two competing declarations of tputs().

> >> Why doesn't Freebsd know the terminfo database? Can't the one that is
> >> integrated into ncurses be used on FreeBSD?

> > I've been told ncurses 4.2 is incorporated in the FreeBSD 3.1 - but that
> > may still just be a port...

> Yes, there is such a port. Do you think, one could release code that
> works on several machines, while some of them must install a special
> program first?

I don't understand this comment (you seem to be saying that because there
is some reluctance to install a working version of ncurses, that there's
no reason to use packages which use it).

> Curses now is a very old UI, very old, it was old when I first learned
> it in the beginning of the 80's. Most people have forgotten that there

not very old at that point (iirc, it dates to the late 70's, and was still
considered "new" when I encountered it in 1983)

> was a Curses before NCurses came up. cursesmodule now, it bases on
> Curses with NCurses extensions. It is not acceptable to release a

as I understand it, most of the "NCurses extensions" you refer to are
standard in SVr4 curses (color, function keys).

> cursesmodule that wouldn't work on all those platforms it formerly
> worked on. If you intend that, you'll have to give it a new name.
> Furthermore, you can't say, to make cursesmodule work, you have got to
> download another one, it's beta, but maybe, it works on your desolated
> site. But that's no solution. That's a cramp.

> Anyway, that wouldn't have helped in my case, I think, since the name
> conflict would have still existed - libtermcap would have been linked
> before, since libreadline demands it, and, I'm afraid, since ncurses
> originally defines tputs(), it would also been mis-linked. I don't
> really know, I guess. I'm not so familiar with the dynamic linking
> rules under ELF/BSD.

that's a different problem (libreadline doesn't mix with curses on any
system because it makes incompatible assumptions about terminal initalization).

> cu
> k.j.


> --
> Support Julia Hill - save the Redwood trees: http://www.lunatree.org/

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey