X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 	tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <4B565125.9010708@cwilson.fastmail.fm>
References: <d37e30051001190453qdb0764br75e5bba1a0fdfbfd AT mail DOT gmail DOT com> 	 <6910a61001190636y6fd704f7p57af4260f2fd31fb AT mail DOT gmail DOT com> 	 <4B565125 DOT 9010708 AT cwilson DOT fastmail DOT fm>
Date: Wed, 20 Jan 2010 14:10:35 +0100
Message-ID: <6910a61001200510o69eb19a1hbe319eb2634b4015@mail.gmail.com>
Subject: Re: Problem with compiling Perl Curses.pm
From: Reini Urban <rurban AT x-ray DOT at>
To: cygwin AT cygwin DOT com
Cc: Jurgen Defurne <jurgen DOT defurne AT gmail DOT com>, bug-Curses AT rt DOT cpan DOT org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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:
>>
>> /*
>> =A0* For reentrant code, we map the various global variables into SCREEN=
 by
>> =A0* using functions to access them.
>> =A0*/
>> #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. =A0That'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 unsupporte=
d.
Interestingly this change is not documented.

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

> 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. =A0But 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. =A0Maybe 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. =A0Or 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". =A0Furthermore, 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. =A0Only, 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.
--=20
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