Re: [patch] remove config.status race condition

On Fri, Feb 23, 2001 at 08:05:26PM +0100, Akim Demaille wrote: : Second means consists in just using $$. We have room for this: : s/conftest/conf$$/, I really can't understand why we'd need something : more complex. Good call. Lars J -- Innovation is one percent inspiration and ninetynine pe

Problems with GMP

Hi, I am having some problems when I try to use autconf with the gmp library. I have the library installed in /usr/local/lib. For example I have /usr/local/lib/libgmp.a. The problem is that if I have a configure.in with the lines AC_CHECK_LIB(gmp, mpz_init, ,

Re: Problems with GMP

What does config.log say about it?

Running make for autoconf V2.13 with HP-UX 11.0

Hello Ben, I guess you get mails like this all the time. I am trying to build autoconf V2.13 for HP-UX 11.0 I have run the configure for autoconf but I cannot make it. Here is the output. Any ideas? Many Thanks, Paul K:/arbor/data/BUSMARK_WORK_DATA/pstevens/autoconf-2.13> ./configure creating

Re: Running make for autoconf V2.13 with HP-UX 11.0

"Stevens, Paul (EDS)" <[EMAIL PROTECTED]> writes: > Hello Ben, > > I guess you get mails like this all the time. Nope. > I am trying to build autoconf V2.13 for HP-UX 11.0 Ah, then this is the explanation of it all :) > K:/arbor/data/BUSMARK_WORK_DATA/pstevens/autoconf-2.13> make > r

Fortran source in subdirectories for libraries

I have directory with: lib_LIBRARIES = libjunk.a libjunk_a_SOURCES = src/a/a.f \ src/b/b.c run configure and gmake and get this: $ gmake source='src/b/b.c' object='b.o' libtool=no \ depfile='.deps/b.Po' tmpdepfile='.deps/b.TPo' \ depmode=gcc /bin/sh ../test/depcomp \ gcc -D

AC_OUTPUT eats VPATH

Hi, AC_OUTPUT seems a little agressive in terms of optimizing VPATH away from makefiles. Looking at the code in acgeneral.m4 : # VPATH is dangerous, but if there is a colon in the path, we need to # keep it. if test "x$srcdir" = x.; then ac_vpsub=['/^[]*VPATH[]*=[^:]*$/

Re: Problems with GMP

Jorge Andres Devoto <[EMAIL PROTECTED]> writes: > > I am having some problems when I try to use autconf with the gmp > library. I have the library installed > in /usr/local/lib. For example I have /usr/local/lib/libgmp.a. > > The problem is that if I have a configure.in with the lines > > AC_CHE

Re: Problems with GMP

Thanks, It seems to work now.

Re: Problems with GMP

Kevin Ryde <[EMAIL PROTECTED]> writes: Jorge Andres Devoto <[EMAIL PROTECTED]> writes: > > I am having some problems when I try to use autconf with the gmp > library. I have the library installed > in /usr/local/lib. For example I have /usr/local/lib/libgmp.a. > > The problem is th

Re: Problems with GMP

Torbjorn Granlund <[EMAIL PROTECTED]> writes: > > Isn't the proper to check for GMP to #include gmp.h > in such probing code? We might want to play with > the names used in a static (not dynamic!) libgmp.a, > making any fixed test unreliable. Unfortunately the basic AC_CHECK_LIB doesn't give a m

Are we ready for 2.49d?

I think we are. Remains autoupdate's Perl problem, but Pavel has a fix for it. ?

Canonical system names

Hi, On some systems there are more variables which distinguish configurations than simply cpu, vendor and os. On mips and sparc for example you can build 32 or 64 bit code, and on, say, a mips R10K you can build your code using either the mips3 or the mips4 instruction set. What's the "proper" wa

Re: Are we ready for 2.49d?

Pavel Roskin <[EMAIL PROTECTED]> writes: > Hello, Akim! > > > I think we are. Remains autoupdate's Perl problem, but Pavel has a > > fix for it. > > Ok to apply my fix? Better fix can be applied later, but the testsuite > must pass. Agreed (= ok). > I'll report the results of my testing toni

Re: Are we ready for 2.49d?

Hello, Akim! > I think we are. Remains autoupdate's Perl problem, but Pavel has a > fix for it. Ok to apply my fix? Better fix can be applied later, but the testsuite must pass. I also think we are ready, but I'll do some testing first. We should check it on GNU/Linux (with bash-1.x, bash-2.x,

Re: Fortran source in subdirectories for libraries

On Feb 26, 2001, Paul Martinolich <[EMAIL PROTECTED]> wrote: > So the fortran source is just skipped. In the Makefile generated by > configure, the .c.o and .f.o are very different. This has nothing to do with autoconf. Apparently, you're using a CVS version of automake to generate Makefiles,

2.49d candidate and Ultrix

Akim, I just did a CVS update of the latest autoconf, built it, and tried to run "make check". Every test is failing. Harlan --- ... /bin/sh testsuite Testing suite for GNU Autoconf 2.49d Some tests might be skipped if

Re: 2.49d candidate and Ultrix

Hello, Harlan! > I just did a CVS update of the latest autoconf, built it, and tried to > run "make check". > > Every test is failing. Thank you for testing, but it's very important that you give up more information. Please change directory to "test" and run ./testsuite 1 2 3 and send the out

Harlan Stenn:

Testing suite log for GNU Autoconf 2.49d /home/stenn/src/gnu/autoconf/ChangeLog : | 2001-02-26 Pavel Roskin <[EMAIL PROTECTED]> | | * autoupdate.in: Preserve exit status of the failed command when |

Autoconf testing results.

Hello! Here are some results. I didn't try to investigate the problems. Instead I tried to get a general picture. RedHat Linux 7.0 bash-2.04: ok RedHat Linux 6.2 bash-1.14.7: ok (very rare intermittent failure). There was one failure that couldn't be reproduced. But I see such things app