RE: [Compile Issue] ncurses 6.4+ on NonStop x86 in configure

[rsbecker]

On January 19, 2025 2:09 PM, Thomas Dickey wrote:
>On Sun, Jan 19, 2025 at 01:37:53PM -0500, rsbecker@nexbridge.com wrote:
>> Hi Thomas,
>>
>> I have a request. In trying to build wide-char on HPE NonStop x86, I
>> found an Issue in their header files and I cannot work around easily
>> from this end.
>> The
>> following patch would address the incompatibility between c11 and
>> c11++. It comes down to the use of intptr_t. Would this patch be
>> possible to integrate into configure? It is an old issue, but 6.4 is
>> the first time I have tried to do this in many years.
>
>6.5 is current (from last spring)
>
>> diff --git a/configure b/configure
>> index 412e5af2..94d287f1 100755
>> --- a/configure
>> +++ b/configure
>> @@ -22881,7 +22881,13 @@ if test "$ac_cv_type_intptr_t" = yes; then
>> else
>>
>>  cat >>confdefs.h <<EOF
>> -#define intptr_t long
>> +#if defined (__TANDEM)
>> +# if ! defined (__cplusplus)
>> +#  define intptr_t long
>> +# endif
>> +#else
>> +# define intptr_t long
>> +#endif
>>  EOF
>
>well yes, it's doable, but would be nice to know more.
>Changing that would change the autoconf tool, not just ncurses.
>Knowing more might lead to a better solution.
>
>In a quick check, I don't see that chunk of the configure script having
changed for
>quite a while (before ncurses ying6.0 actually).
>
>Your diff modifies this macro call from configure.in:
>
>       AC_CHECK_TYPE(intptr_t, long)
>
>ncurses doesn't use intptr_t in its C++ binding:
>
>ncurses/curses.priv.h:142:# define CASTxPTR(n)    (unsigned
>long)(intptr_t)(void*)(n)
>ncurses/curses.priv.h:144:# define CASTxPTR(n)    (intptr_t)(n)
>ncurses/win32con/win_driver.c:1875:    intptr_t value = _get_osfhandle(fd);
>ncurses/base/lib_getch.c:142:    intptr_t value = _get_osfhandle(fd);
>ncurses/tinfo/lib_win32con.c:161:    intptr_t value = _get_osfhandle(fd);
>package/mingw-ncurses.spec:77: --with-tparm-arg=intptr_t \\\
>progs/toe.c:298:    if ((intptr_t) value == (intptr_t) (-1)) {
>test/test.priv.h:492:#define my_intptr_t       intptr_t
>test/test.priv.h:494:#define my_intptr_t       long
>test/picsmap.c:97:#define P2I(n) (((int)(my_intptr_t)(n)) - 1)
>test/picsmap.c:98:#define I2P(n) (void *)(my_intptr_t)((n) + 1)
>test/test_tparm.c:231:                   ? (long) (my_intptr_t) (number[n]
\
>
>and
>
>ncurses/curses.priv.h:142:# define CASTxPTR(n)    (unsigned
>long)(intptr_t)(void*)(n)
>ncurses/curses.priv.h:144:# define CASTxPTR(n)    (intptr_t)(n)
>ncurses/curses.priv.h:149:# undef CASTxPTR
>ncurses/curses.priv.h:150:# define CASTxPTR(n)    (long)(void*)(n)
>ncurses/trace/lib_trace.c:265:             CASTxPTR(pthread_self().p)
>ncurses/trace/lib_trace.c:267:             CASTxPTR(pthread_self())
>ncurses/tinfo/comp_parse.c:230:           (void *) fp, buf, literal,
silent,
>CASTxPTR(hook)));
>
>making it needed in a regular build in just two places:
>
>ncurses/tinfo/comp_parse.c:230:           (void *) fp, buf, literal,
silent,
>CASTxPTR(hook)));
>progs/toe.c:298:    if ((intptr_t) value == (intptr_t) (-1)) {
>
>so I'm unclear why there's some special case for C++, because that
shouldn't be
>related.  (If there were some AC_DEFINE, that could affect the generated
headers,
>but I don't see that, either).

I think this is a compatibility issue with the C++ header files supplied by
the hardware vendor. It has been reported.
They are also behind in autoconf. For now, I guess I will keep a separate
fork with this change.

Regards,
Randall