Re: Issue with gl_WCHAR_H on z/OS

[Ralf Wildenhues]

Hello Steve, all,

* Steve Goetze wrote on Thu, Apr 15, 2010 at 05:52:27PM CEST:
> This test is intended to check for <wchar.h> issues related to gcc and the
> transition from __inline to gnu_inline.  It is located in "m4/wchar.m4" in
> m4-1.4.14.  When compiling on z/OS with the IBM xlc compiler, the test fails
> for an unrelated reason:  When running the compiler on z/OS with the
> -qxplink option (this is preferred),

What does -qxplink do and why is it preferred?

> the test itself compiles two object
> files that are linked together.  Because the source file names for both
> files is the traditional "conftest.c", they cause identical CSECT names to
> be generated, resulting in a link error.  There are several ways to work
> around this issue - I'd appreciate any advice on the best approach.

Interesting failure.  I think we could parameterize $ac_compile to
accept a different source file name, e.g., ac_source_stem=conftest.
I've come across similar (nonfatal) issues with a test in libtool.m4
when using gcc 4.5 with -flto.

Arising portability issues are: the need to reliably clean up all files
in question, we cannot exploit conftest*.* if 8.3 file names are still
to be honored.

But anyway tests with more than one input file will only become more
important, if only for (bugs in) cross-file optimizations and the like.

Of course, beside all that, if you use libtool you might come across it
renaming object files at library link time at will (if you happen to
link to objects with the same basename into a library), which will
still break.

Thanks for the report.

Cheers,
Ralf