Re: Problem with compiling Perl Curses.pm

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Reini Urban wrote:
> Then CursesVar.c is regenerated by gen\make.CursesVar.c
> It looks like this generation got triggered somehow and gets it wrong.
> Because the DLL exporting part of ncurses/ncurses_dll.h does:
> 
> /*
>  * For reentrant code, we map the various global variables into SCREEN by
>  * using functions to access them.
>  */
> #define NCURSES_PUBLIC_VAR(name) ncwrap_##name
> #define NCURSES_WRAPPED_VAR(type,name) extern type
> NCURSES_PUBLIC_VAR(name)(void)

Uhm no, that's not wrong.  That's correct. It's a consequence of cygwin
finally moving from what upstream ncurses calls "ABI 5" to what they
call "ABI 6" [*].

We now build with support for re-entrancy, which requires a few ABI
changes of this sort. Which means that you really can't change the value
of LINES in this way -- there may be another way, but I'm not sure what
it is.

Besides, I don't think changing the value of the LINES "C" variable
outside of curses was ever really supposed to work. The documentation
says that LINES will be "populated" by initscr() using the value of the
*environment variable* LINES, or if that's empty, then it will be
populated from the terminfo description.  But the docs are silent as to
what happens if you manually modify that "C" variable after initscr().

Anyway, I looked at the bug report thread, and I think your Tue Jan 19
11:16:23 2010 response is the correct one. You just shouldn't write to
those variables, AFAICT.  Maybe there is some set_FOO() function that
could be used, but I don't know what it is; and for /some/ of these
particular variables it just conceptually doesn't really make sense to
change them once initscr() is complete. (You should be able to update
COLORS and COLOR_PAIRS...I think there are accessor functions for that.)

You're also right that this will affect more platforms than just cygwin,
once they start enabling re-entrancy -- which is slated to be the
default when ncurses-6 is released upstream. 'Course, that may not
happen for a year.  Or two or three.


[*] cygwin *used* be be at ABI 5 -- actually, because of issues with
DLLs and exported "complex" data structures in the historical absence of
pseudo-reloc support, we were really using a somewhat bastardized form
of ABI "5.5".  Furthermore, because of certain other historical changes
-- ABI jumps required by new compilers, the cygwin-1.3 to -1.5
transition, and ABI-breaking bugfixes -- our ABI "5" or "5.5" was
actually cygncurses-9.

Well, now, we're actually using the true upstream ABI 6.  Only, we have
to call it cygncurses-10.

Isn't this fun?

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple