| CC: | Jurgen Defurne <jurgen.defurne [...] gmail.com>, bug-Curses [...] rt.cpan.org |
| Subject: | Re: Problem with compiling Perl Curses.pm |
| Date: | Wed, 20 Jan 2010 14:10:35 +0100 |
| To: | cygwin [...] cygwin.com |
| From: | Reini Urban <rurban [...] x-ray.at> |
2010/1/20 Charles Wilson:
Show quoted text
> Reini Urban wrote:
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
Show quoted text>> 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.)
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."
Show quoted text> 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/