On Mon, 2017 Oct 9 18:11+0200, Bruno Haible wrote:
>
> 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.
Environment variables are still respected in the Gawk framework. Gawk is
somewhat of an oddball anyway, being such a base-level dependency for
other parts of the GNU system. But other packages should eventually be
able to gain similar logic "for free."
> 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 "compile" script appears to be narrowly aimed at compilers that
don't understand "-c -o", however. If it could be broadened from that,
then yes, this would be a good place to put the XLC logic.
> The user then only needs to have a specific set of environment
> variables for each machine. Like this (for AIX):
[...]
That all still works, with the exception of some z/OS compilers (c89)
that require options to be passed in the _C89_OPTIONS environment
variable due to quoting issues.
> 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?
No prototype for duplocale() exists in the system headers. There is
a symbol for it present in the C library, and the configure check
picks this up. But if you attempt to call the function, you get a
runtime error:
cat duplocale-test.c
#include <locale.h>
int main(void)
{
return duplocale(NULL);
}
$ xlc -o duplocale-test duplocale-test.c
$ ./duplocale-test
CEE3728S The use of a function, which is not supported by this release of
Language Environment was detected.
From entry point main at compile unit offset +0000005E at entry
offset +0000005E at address 1CE0A986.
Killed
My impression is that a stub was added to facilitate porting, but you're
not supposed to actually use it. (Locale support on z/OS is quite
limited anyway.)
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
