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
