[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue with gl_WCHAR_H on z/OS
From: |
Steve Goetze |
Subject: |
Re: Issue with gl_WCHAR_H on z/OS |
Date: |
Fri, 16 Apr 2010 12:00:47 -0400 |
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
>