Re: Build error due to missing locale_t on IBM z/OS

[Bruno Haible]

Hi Daniel,

> > 1) What is 'xlc-wrap', compared to 'xlc'? (I'd like to know if
> >    something is missing in Autoconf or gnulib-common.m4.)
> 
> xlc-wrap is my own script. It is quite simple:
> 
>     #!/bin/sh
>     exec xlc -qnosearch "$@" -qsearch=/usr/include
> 
> It is used to work around a non-standard behavior of the compiler, where
> /usr/include/ is effectively first in the header search path (before any
> -I directories). Obviously an issue for Gnulib's replacement headers.
> 
> I haven't gotten around yet to submitting this issue formally to Gnulib.
> For an example of how such a workaround can be integrated, look at
> AC_ZOS_USS in m4/arch.m4 in the GNU Gawk source.

Thanks, I understand. However, I don't think it is adequate to put this into
a specific package (gawk) or gnulib; rather, I like the way Autoconf-generated
configure files obey the environment variables.
For even difficult cases (msvc builds on Windows) this approach is sufficient:
Autoconf/Automake maintains a 'compile' script (that the user can modify locally
if needed); the user sets an environment variable (CC) to point to this script.
This way
  - the same recipe works for most GNU packages,
  - individual GNU package maintainers don't need to change their build system,
  - the wrapper script can be maintained in a central place.

The user then only needs to have a specific set of environment variables for
each machine. Like this (for AIX):
  CC="xlc -q64"; CXX="xlC -q64"; AR="ar -X 64"; NM="nm -X 64"; export CC CXX AR 
NM
or this (for native Windows):
  CC="$HOME/msvc/compile cl -nologo"; export CC
  CFLAGS="-MD"; export CFLAGS
  CXX="$HOME/msvc/compile cl -nologo"; export CXX
  CXXFLAGS="-MD"; export CXXFLAGS
  CPPFLAGS="-D_WIN32_WINNT=$win32_target -I/usr/local/msvc64/include"; export 
CPPFLAGS
  LDFLAGS="-L/usr/local/msvc64/lib"; export LDFLAGS
  LD="link"; export LD
  NM="dumpbin -symbols"; export NM
  STRIP=":"; export STRIP
  AR="$HOME/msvc/ar-lib lib"; export AR
  RANLIB=":"; export RANLIB

> > 2) 
> > > ERROR CCN3166 ./locale.h:648   Definition of function locale_t requires 
> > > parentheses.
> > > ERROR CCN3276 ./locale.h:648   Syntax error: possible missing '{'?
> > 
> > Can you show the lines around 648 in the generated locale.h?
> > Unfortunately the line numbers in locale.h and locale.in.h are not
> > the same.
> 
> Line 648 is marked below:
> 
> -----begin locale.h excerpt-----
> #if 1
> # if 1
> #  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
> #   undef duplocale
> #   define duplocale rpl_duplocale
> #  endif
> _GL_FUNCDECL_RPL (duplocale, locale_t, (locale_t locale) _GL_ARG_NONNULL 
> ((1))); <---HERE
> _GL_CXXALIAS_RPL (duplocale, locale_t, (locale_t locale));
> # else
> #  if 1
> _GL_CXXALIAS_SYS (duplocale, locale_t, (locale_t locale));
> #  endif
> # endif
> # if 1
> _GL_CXXALIASWARN (duplocale);
> -----end locale.h excerpt-----
> 
> When I looked at the preprocessed source, the first mention of locale_t
> came from that line. So it seems that while all other systems provide
> locale_t, z/OS is an exception.

But the autoconfiguration found that HAVE_DUPLOCALE=1 and REPLACE_DUPLOCALE=1.
So, there must be a duplocale function somewhere. Is it declared somewhere, and
if yes, what is its prototype?

> > 3)
> > > ERROR CCN3273 /usr/include/stdlib.h:64    Missing type in declaration of 
> > > div_t.
> > > ERROR CCN3166 /usr/include/stdlib.h:544   Definition of function div_t 
> > > requires parentheses.
> > 
> > Can you show the lines around 64 and 544 in /usr/include/stdlib.h?
> 
> These errors are probably cascaded from the earlier syntax error, so I
> wouldn't worry about them for now.

OK.

Bruno