Subject: Re: Problem with compiling Perl Curses.pm
From: Reini Urban <[email-masked]>
To: [email-masked]
Cc: Jurgen Defurne <[email-masked]>, [email-masked]
Date: Wed, 20 Jan 2010 14:10:35 +0100
List-Id: <cygwin.cygwin.com>

2010/1/20 Charles Wilson:
> 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" [*].

Thanks. I also found that out afterwards.
Getting those public vars is still supported, but setting is now unsupported.
Interestingly this change is not documented.

See http://rt.cpan.org/Ticket/Display.html?id=53818

> 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.)

I haven't found any set_FOO().

I wrote into my perl patch:

"I'm sorry. I had to disable writing to LINES, COLS, curscr, stdscr,
COLORS, COLOR_PAIRS, because with the new NCURSES_REENTRANT lib, writing
is forbidden. It's now wrapped behind a function call.
I believe this affects all platforms, but some ncurses expert
should clarify how to write to LINES now."

> 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?

Thanksfully this is not problematic, than silently breaking setters.
Maybe they didn't know that people were also setting those vars.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

--
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