[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Testsuite failures on UnixWare 7.1.1
From: |
Akim Demaille |
Subject: |
Re: Testsuite failures on UnixWare 7.1.1 |
Date: |
29 Jan 2001 15:09:33 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake) |
| Alexandre Oliva wrote:
| >
| > On Jan 26, 2001, Matt Schalit <address@hidden> wrote:
| >
| > > I'm concerned that the CVS version will have more bugs in it.
| > > If it's not stable, then I thought it's not stable.
| >
| > Maybe using yesterday's candidate release, just taken out of the CVS
| > tree, would make you feel better? We'd rather hash out any bugs
| > before the release :-) That's why I suggested you might want to try
| > the CVS tree...
| >
| > --
| > Alexandre Oliva
|
|
| Ok here's what happened when I tried the cvs checkout autoconf
| on Friday night:
|
| I moved my gcc to gcc.orig, so autoconf would compile with
| /usr/bin/cc. (The reason is I'm having a problem where any
| configure script that tries to use gcc also tries to use
| /usr/local/i586-sco-sysv5uw7.1.1/bin/as
| instead of /usr/bin/as. The /usr/local version of as doesn't
| understand -Qy.
|
| Using ./configure, cc to compile, and gnu make to make.
|
| gmake check failed one test:
|
| ========================================
| Testing suite log for GNU Autoconf 2.49d
| ========================================
|
| Failed tests:
| 37: compile.at:205 GNU Fortran 77
|
| Skipped tests:
| 9: tools.at:411 autoupdate
| 10: tools.at:447 autoupdating AC_LINK_FILES
| 11: tools.at:476 autoupdating AC_PREREQ
| 50: foreign.at:9 Autoconf & Libtool
|
|
| [snip]
|
| configure:974: checking for pgf90
| configure:999: result: no
| configure:974: checking for fc
| configure:996: result: fc
| configure:1009: checking for object suffix
| configure:1020: fc -c conftest.f >&5
| /usr/bin/fc[14]: fc: -c: unknown option
| Usage: fc [-lnrs] [-e editor] [-N #] [first] [last]
| configure:1023: $? = 2
| configure: failed program was:
| program main
|
| end
| configure:1035: error: cannot compute OBJEXT: cannot compile
That was to be expected... I didn't like too much the changing of the
order between computing EXEEXT/OBJEXT and _WORKS, since it is the
later that exits ``gracefully'' when the compiler is broken (exit 77).
We have to do something about it, Tim.