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 <Ralf.Wildenhues@xxxxxx>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 > _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
