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

[Thomas Dickey]

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)
 
> Thanks,
> Randall
> 
> 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).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

signature.asc
Description: PGP signature