Re: Issue with gl_WCHAR_H on z/OS

[Steve Goetze]

Ralf,

Thanks for looking at this.  XPLINK is a compiler / linker option on z/OS
that provides better performance for subroutine calls.  It is required when
compiling LP64, optional but recommended for ILP32.

I'll patch around this test for the time being - your point about multiple
input files in tests is well taken.

--Steve

On Fri, Apr 16, 2010 at 1:36 AM, Ralf Wildenhues <address@hidden>wrote:

> 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
>