| I was looking back at the ChangeLog when I noticed this:
| 2000-05-23 Akim Demaille [EMAIL PROTECTED]
|
| Simplify the interface: users shouldn't need to explicitly check
| for special environments.
|
| * acspecific.m4 (AC_EXEEXT, AC_OBJEXT): AU defined to
|
I have seen this error a number of times, but it does not seem
to be reproducible. Has anyone run into anything like this
using the CVS version of autoconf? It seems to happen during
this Macro eval:
AC_CHECK_HEADERS(ctype.h time.h float.h)
./configure
...
checking for time.h... yes
checking
Hi,
We had some problems with getting our Coin project compiled on Cygwin,
which we traced back to some "^M"-characters that weren't removed from
directory- and file-names when the dependeny tracking files were about
to be created at the end of the config.status run.
The following patch made
On Wed, 7 Jun 2000, Lars J. Aas wrote:
We had some problems with getting our Coin project compiled on Cygwin,
which we traced back to some "^M"-characters that weren't removed from
directory- and file-names when the dependeny tracking files were about
to be created at the end of the
--- "Thomas E. Dickey" [EMAIL PROTECTED] wrote:
On Wed, 7 Jun 2000, Lars J. Aas wrote:
We had some problems with getting our Coin project compiled on Cygwin,
which we traced back to some "^M"-characters that weren't removed from
directory- and file-names when the dependeny tracking files
I am using the Absoft F77 Compiler for Linux since it can handle Fortran
structures and I've run into a problem using AC_F77_LIBRARY_LDFLAGS in the
CVS autoconf as of June 6th. I had used an earlier CVS version from around
last Decemeber which worked fine, but I don't have that copy anymore...
Akim Demaille writes:
I think Autoconf should advocate a single approach.
Yup.
Also, is `HAVE_WORKING_FOO' the right naming scheme? Is it powerful
enough to allow us the specify the various brokenness that this or
that function may have? Should HAVE_WORKING_FOO always be the `or' of
On Wed, Jun 07, 2000 at 07:04:55AM -0700, Earnie Boyd wrote:
: --- "Thomas E. Dickey" [EMAIL PROTECTED] wrote:
: On Wed, 7 Jun 2000, Lars J. Aas wrote:
: The following patch made the configure script work, but one should
: probably find out how the ^M characters were introduced and fix it on
--- "Lars J. Aas" [EMAIL PROTECTED] wrote:
On Wed, Jun 07, 2000 at 07:04:55AM -0700, Earnie Boyd wrote:
: --- "Thomas E. Dickey" [EMAIL PROTECTED] wrote:
: On Wed, 7 Jun 2000, Lars J. Aas wrote:
: The following patch made the configure script work, but one should
: probably find out how
| configure:1039: /usr/absoft/bin/f77 -o conftest conftest.f 5
| FORTRAN 77 Compiler 4.5, Copyright (c) 1987-1999, Absoft Corp.
Hm, are you telling us that your compiler is always outputting
something when it compiles?
cat conftest.f EOF
program conftest
end
EOF
%% Peter Eisentraut [EMAIL PROTECTED] writes:
pe "Working" is a fairly volatile term. free() "works" if it frees
pe memory. If it doesn't grok null pointers, that's an unfortunate
pe circumstance but not necessarily "not working" by all standards.
Actually, not so. All the C standards
$ more config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure 2.14a, executed with
../configure
configure:595: checking for gcc
configure:617: result: gcc
configure:709: checking
+ ../autoupdate -m .. -
c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
[c:/djgpp/tmp/au16317/m4.m4]: No such file or directory (ENOENT)
c:/djgpp/tmp/au16317/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
After playing with generated temporary files, it seems like a
Akim wrote:
Also, what the heck is doing this:
| configure:1069: /usr/absoft/bin/f77 -E conftest.fpp
| conftest.fpp:2:
| yes
| ^
| Non-numeric character at (^) in label field [info -f g77 M LEX]
| configure:1075: result: no
That's in _AC_PROG_F77_GNU
in the log file? The `[info -f
I wrote:
Absoft's compiler apparently falls into (4). This is fine; the test gives
the correct result: he's not using g77.
Whoops, oh I see. Absoft falls into case (6): compiler doesn't recognize
.fpp, and "helpfully" passes the buck to another compiler (g77), but
without the -E flag. Hence
Paul Martinolich wrote:
According to their documentation, .fpp is not a valid extension, so
maybe they default to g77 in this case. They use .F for preprocessed
FORTRAN. If I use .F, then I get a usage error (for -E).
I've never heard of anyone using .fpp either, and .F is fairly standard (as
16 matches
Mail list logo
