AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Bauer, Christoph]

> Done; built and tested on Mac OS X (using X instead of Carbon, of
> course).
> Christoph, would you care to update from CVS and try the HP-UX build
> again, just to be sure?

The gcc build on HP-UX works now with the latest CVS version.

Re: AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Ken Raeburn]

On Mar 22, 2006, at 04:57, Bauer, Christoph wrote:
> The gcc build on HP-UX works now with the latest CVS version.

Excellent; thank you for checking.

Ken

AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Bauer, Christoph]

>     cc fails with this error in lib-src:
> 
>     cc -DHAVE_CONFIG_H    -I. -I../src -
> I/T/tools/unix/build/emacs/emacs/lib-src
>     -I/T/tools/unix/build/emacs/emacs/lib-src/../src   -g
>     /T/tools/unix/build/emacs/emacs/lib-src/fakemail.c -l:libdld.sl      -
> o
>     fakemail
>     cpp: "/T/tools/unix/build/emacs/emacs/lib-src/../src/s/hpux9.h", line
> 63:
>     warning 2001: Redefinition of macro HAVE_PSTAT_GETDYNAMIC.
>     cc: "/usr/include/sys/_mbstate_t.h", line 11: error 1000: Unexpected
> symbol:
>     "int".
>     cc: "/usr/include/stdlib.h", line 117: warning 573: Parameter list is
>     inconsistent for "getenv".
> 
> Would you like to debug it and send a patch we can try?

I don't have a complete fix, but a first explanation for the message.

src/config.h contains

/* Define to 1 if <wchar.h> declares mbstate_t. */
/* #undef HAVE_MBSTATE_T */

#define HAVE_SYS__MBSTATE_T_H 1

#define mbstate_t int

/* End of config.h */

But <sys/_mbstate_t.h> defines mbstate_t as a struct. This leads to
the syntax error above. src/config.h from the gcc-build doesn't 
define mbstate_t. configure.in:AC_TYPE_MSTATE_T
generates a test program, which includes only <wchar.h>.

Here is a patch for configure.in with a workaround:

diff -r1.406 configure.in
2695a2696,2700
> echo "$ac_cv_header_sys__mbstate_t_h"
> if test "$ac_cv_header_sys__mbstate_t_h" = "yes"; then
>    ac_cv_type_mbstate_t="yes"
> fi
>

There is a second problem, which is located in src/strftime.c.

#ifdef _LIBC
...
# define MULTIBYTE_IS_FORMAT_SAFE 1
...
#endif 
...

#define DO_MULTIBYTE (HAVE_MBLEN && ! MULTIBYTE_IS_FORMAT_SAFE)

#if DO_MULTIBYTE
# if HAVE_MBRLEN
#  include <wchar.h>
#   ifdef HAVE_SYS__MBSTATE_H	/* previously tested __hpux */
#     include <sys/_mbstate_t.h>
#   endif
#  if !defined (mbsinit) && !defined (HAVE_MBSINIT)
#   define mbsinit(ps) 1
#  endif /* !defined (mbsinit) && !defined (HAVE_MBSINIT) */

So <sys/_mbstate_t.h> is not included (_LIBC in not defined).
When I define MULTIBYTE_IS_FORMAT_SAFE in config.h, the build
succeeds. 

Re: AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    So <sys/_mbstate_t.h> is not included (_LIBC in not defined).
    When I define MULTIBYTE_IS_FORMAT_SAFE in config.h, the build
    succeeds. 

That does not necessarily mean it is correct to define that
symbol.  Here's the explanation of it:

    /* Do multibyte processing if multibytes are supported, unless
       multibyte sequences are safe in formats.  Multibyte sequences are
       safe if they cannot contain byte sequences that look like format
       conversion specifications.  The GNU C Library uses UTF8 multibyte
       encoding, which is safe for formats, but strftime.c can be used
       with other C libraries that use unsafe encodings.  */
    #define DO_MULTIBYTE (HAVE_MBLEN && ! MULTIBYTE_IS_FORMAT_SAFE)

So, are multibyte sequences safe on your system?

AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Christoph Bauer]

> 
> Are you saying you think that compiling everything with 
> -D_INCLUDE__STDC_A1_SOURCE is the correct change?
> 

Yes. 

Re: AW: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error]

[Richard Stallman]

    > Are you saying you think that compiling everything with 
    > -D_INCLUDE__STDC_A1_SOURCE is the correct change?
    > 

    Yes. 

Can you suggest a patch to configure.in or
to the m/*.h or s/*.h file that will do this?