Nabble - Gnu - Autoconf

Re: Bug#560105: autoconf: AC_TYPE_INT32_T generates broken test?

2009-12-09T10:56:18Z

* Eric Blake wrote on Wed, Dec 09, 2009 at 01:38:00PM CET:
> According to Ralf Wildenhues on 12/8/2009 11:25 PM:
> > * Ralf Wildenhues wrote on Tue, Dec 08, 2009 at 11:59:26PM CET:
> >> * Pierre Ynard wrote on Tue, Dec 08, 2009 at 11:42:02PM CET:
> >>> AC_TYPE_INT32_T, and also AC_TYPE_INT16_T and AC_TYPE_INT64_T, output C
> >>> code that looks like:
> >
> > Patch below. OK to commit and add Pierre to THANKS?
>
> Yes, please.

Thanks. Pushed, after fixing the description and NEWS entry to mention
2.65 not 2.64.

I also pushed this patch which fixes the other wrong NEWS entry.

Cheers,
Ralf

Fix NEWS description for AC_FUNC_MMAP entry.

* NEWS: Update.

diff --git a/NEWS b/NEWS
index d24db8a..69cca79 100644
--- a/NEWS
+++ b/NEWS
@@ -3,7 +3,7 @@ GNU Autoconf NEWS - User visible changes.
* Major changes in Autoconf 2.65a (????-??-??) [experimental]
Released by ???? ????

-** AC_FUNC_MMAP works in C++ mode again. Regression introduced in 2.64.
+** AC_FUNC_MMAP works in C++ mode again. Regression introduced in 2.65.

** Use of m4_divert without a named diversion now issues a syntax warning,
since it is seldom right to change diversions behind autoconf's back.

From forum: Gnu - Autoconf - Bugs

automake-1.11.1 test failure on Mac OS X 10.6

2009-12-09T09:36:31Z

Hi,

Yes this is the right list :)

Automake's instspc.test fails when prefix has a ^M in it, it becomes an
r on darwin:

/usr/bin/install -c -m 644 ../sub/nobase.h
'/Users/leodavis/autotools-new/automake-1.11/tests/instspc.dir/sub1/r-prefix/foo/sub'
test -f
'/Users/leodavis/autotools-new/automake-1.11/tests/instspc.dir/sub1/^M-prefix/foo/sub/nobase.h'
make: *** [test-install-sep] Error 1
+ eval 'build_failures="$build_failures

status.m4 has:
ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' </dev/null 2>/dev/null`
if test "$ac_cs_awk_cr" = "a${ac_cr}b"; then
ac_cs_awk_cr='\r'
else
ac_cs_awk_cr=$ac_cr
fi

ac_cs_awk_cr seems to be getting set to '\r' - is this correct?

Then later:
cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
else
cat
fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
|| AC_MSG_ERROR([could not setup config files machinery])
_ACEOF

The sed changes ^M to r:
$ printf "a^Mb" | sed 's/^M/\r/'
arb

It works with GNU sed:
printf "a^Mb" | sed 's/^M/\r/' | hexdump
0000000 61 0d 62
0000003

Peter
--
Peter O'Gorman
http://pogma.com

From forum: Gnu - Autoconf - Bugs

Re: m4sugar test 'recursion' fails

2009-12-09T04:39:51Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paolo Bonzini on 12/9/2009 2:21 AM:

> Fixed thusly:
>
> diff --git a/tests/m4sugar.at b/tests/m4sugar.at
> index a96583c..4d937cf 100644
> --- a/tests/m4sugar.at
> +++ b/tests/m4sugar.at
> @@ -1874,7 +1874,7 @@ A
> AT_DATA_M4SUGAR([script.4s],
> [[m4_ifdef([__m4_version__],
> [m4_undefine([__m4_version__])],
> -[m4_divert_push(0)48894
> +[m4_divert_push([])48894

Yep, that's the correct fix. Sorry I missed it earlier.

- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksfmpcACgkQ84KuGfSFAYDWrQCfamES5c4JV22gVZHdQX+aflDN
kmcAnRmxUnOx4zQdvaMyC9l7ixHB0Sm7
=9qsP
-----END PGP SIGNATURE-----

From forum: Gnu - Autoconf - Bugs

Re: m4sugar test 'recursion' fails

2009-12-09T04:39:51Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paolo Bonzini on 12/9/2009 2:21 AM:

From forum: Gnu - Autoconf - Patches

Re: Bug#560105: autoconf: AC_TYPE_INT32_T generates broken test?

2009-12-09T04:38:00Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 12/8/2009 11:25 PM:
> * Ralf Wildenhues wrote on Tue, Dec 08, 2009 at 11:59:26PM CET:
>> * Pierre Ynard wrote on Tue, Dec 08, 2009 at 11:42:02PM CET:
>>> AC_TYPE_INT32_T, and also AC_TYPE_INT16_T and AC_TYPE_INT64_T, output C
>>> code that looks like:
>
> Patch below. OK to commit and add Pierre to THANKS?

Yes, please.

>
>> I think we need to start comparing test results against tables for at
>> least a couple of systems, in order to guard against such issues.
>
> My current idea for this is to have a mode in which AT_CHECK_MACRO
> records cache values, or we simply run `testsuite -d' and collect cache
> values across all tests, maybe weeding out or commenting out those that
> are not consistent across the testsuite; then redo the same for an older
> release, and compare.

Not as part of this patch, but the idea seems like it might be worthwhile.

- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksfmigACgkQ84KuGfSFAYBGYQCZARbU/kagiplAzOdCO7t7vrCX
/LkAnjIfRjNGaeHfcSa7VkH76766hs4k
=kyCF
-----END PGP SIGNATURE-----

From forum: Gnu - Autoconf - Bugs

Re: m4sugar test 'recursion' fails

2009-12-09T01:21:53Z

On 12/09/2009 07:41 AM, Ralf Wildenhues wrote:

> Hi Eric,
>
> your recent diversion-name patch caused a new testsuite failure for me:
>
> # -*- compilation -*-
> 69. m4sugar.at:1821: testing ...
> ../../autoconf/tests/m4sugar.at:1859: autom4te --language=m4sugar script.4s -o script -o-
> ../../autoconf/tests/m4sugar.at:1916: autom4te --language=m4sugar script.4s -o script -o-
> --- /dev/null 2008-04-28 20:08:22.000000000 +0200
> +++ /tmp/autoconf/build/tests/testsuite.dir/at-groups/69/stderr 2009-12-07 09:53:15.000000000 +0100
> @@ -0,0 +1 @@
> +script.4s:1: warning: prefer named diversions
> 69. m4sugar.at:1821: 69. recursion (m4sugar.at:1821): FAILED (m4sugar.at:1916)
>
> Cheers,
> Ralf
>
>
>

Fixed thusly:

diff --git a/tests/m4sugar.at b/tests/m4sugar.at
index a96583c..4d937cf 100644
--- a/tests/m4sugar.at
+++ b/tests/m4sugar.at
@@ -1874,7 +1874,7 @@ A
AT_DATA_M4SUGAR([script.4s],
[[m4_ifdef([__m4_version__],
[m4_undefine([__m4_version__])],
-[m4_divert_push(0)48894
+[m4_divert_push([])48894
9999,10000
78896
58894

Paolo

From forum: Gnu - Autoconf - Bugs

Re: m4sugar test 'recursion' fails

2009-12-09T01:21:53Z

On 12/09/2009 07:41 AM, Ralf Wildenhues wrote:

From forum: Gnu - Autoconf - Patches

m4sugar test 'recursion' fails

2009-12-08T22:41:06Z

Hi Eric,

your recent diversion-name patch caused a new testsuite failure for me:

# -*- compilation -*-
69. m4sugar.at:1821: testing ...
../../autoconf/tests/m4sugar.at:1859: autom4te --language=m4sugar script.4s -o script -o-
../../autoconf/tests/m4sugar.at:1916: autom4te --language=m4sugar script.4s -o script -o-
--- /dev/null 2008-04-28 20:08:22.000000000 +0200
+++ /tmp/autoconf/build/tests/testsuite.dir/at-groups/69/stderr 2009-12-07 09:53:15.000000000 +0100
@@ -0,0 +1 @@
+script.4s:1: warning: prefer named diversions
69. m4sugar.at:1821: 69. recursion (m4sugar.at:1821): FAILED (m4sugar.at:1916)

Cheers,
Ralf

From forum: Gnu - Autoconf - Bugs

Re: Bug#560105: autoconf: AC_TYPE_INT32_T generates broken test?

2009-12-08T22:25:33Z

* Ralf Wildenhues wrote on Tue, Dec 08, 2009 at 11:59:26PM CET:
> * Pierre Ynard wrote on Tue, Dec 08, 2009 at 11:42:02PM CET:
> > AC_TYPE_INT32_T, and also AC_TYPE_INT16_T and AC_TYPE_INT64_T, output C
> > code that looks like:

Patch below. OK to commit and add Pierre to THANKS?

> I think we need to start comparing test results against tables for at
> least a couple of systems, in order to guard against such issues.

My current idea for this is to have a mode in which AT_CHECK_MACRO
records cache values, or we simply run `testsuite -d' and collect cache
values across all tests, maybe weeding out or commenting out those that
are not consistent across the testsuite; then redo the same for an older
release, and compare.

Thanks,
Ralf

Fix 2.64 AC_TYPE_INT*_T macro body text regression.

* lib/autoconf/types.m4 (_AC_TYPE_INT_BODY): Move helper enum
definition to prologue section, to avoid syntax error.
* NEWS, THANKS: Update.
Report by Pierre Ynard.

diff --git a/NEWS b/NEWS
index 97dcab0..c36584c 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,9 @@ GNU Autoconf NEWS - User visible changes.
** Use of m4_divert without a named diversion now issues a syntax warning,
since it is seldom right to change diversions behind autoconf's back.

+** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and
+ AC_TYPE_INT64_T work again. Regression introduced in 2.64.
+
* Major changes in Autoconf 2.65 (2009-11-21) [stable]
Released by Eric Blake, based on git versions 2.64.*.

diff --git a/lib/autoconf/types.m4 b/lib/autoconf/types.m4
index 7a73fc2..3829c4c 100644
--- a/lib/autoconf/types.m4
+++ b/lib/autoconf/types.m4
@@ -635,14 +635,14 @@ m4_define([_AC_TYPE_INT_BODY],
'long long int' 'short int' 'signed char'; do
AC_COMPILE_IFELSE(
[AC_LANG_BOOL_COMPILE_TRY(
- [AC_INCLUDES_DEFAULT],
- [enum { N = $[]2 / 2 - 1 };
- 0 < ($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 1)])],
+ [AC_INCLUDES_DEFAULT
+ enum { N = $[]2 / 2 - 1 };],
+ [0 < ($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 1)])],
[AC_COMPILE_IFELSE(
[AC_LANG_BOOL_COMPILE_TRY(
- [AC_INCLUDES_DEFAULT],
- [enum { N = $[]2 / 2 - 1 };
- ($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 1)
+ [AC_INCLUDES_DEFAULT
+ enum { N = $[]2 / 2 - 1 };],
+ [($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 1)
< ($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 2)])],
[],
[AS_CASE([$ac_type], [int$[]2_t],

From forum: Gnu - Autoconf - Bugs

Re: Bug#560105: autoconf: AC_TYPE_INT32_T generates broken test?

2009-12-08T14:59:26Z

tags upstream forwarded
thanks

[ This is <http://bugs.debian.org/560105> ]

Hello Pierre,

thanks for the bug report.

* Pierre Ynard wrote on Tue, Dec 08, 2009 at 11:42:02PM CET:
> AC_TYPE_INT32_T, and also AC_TYPE_INT16_T and AC_TYPE_INT64_T, output C
> code that looks like:

> static int test_array [1 - 2 * !(enum { N = $2 / 2 - 1 };
> 0 < ($ac_type) ((((($ac_type) 1 << N) << N) - 1) * 2 + 1))];
> test_array [0] = 0

> which fails to compile with errors like:
>
> conftest.c: In function 'main':
> conftest.c:73: error: expected ')' before ';' token
> conftest.c:74: error: expected expression before ']' token
>
> Thus, the check always returns no. And then ./configure of project foo
> aborts because it can find its int types...
>
> This problem isn't there in autoconf 2.64-4.

What an ugly regression. Confirmed. bisect converges at:

15f8838bb6239ebc16beb8472de0217a10de3d5e is the first bad commit
commit 15f8838bb6239ebc16beb8472de0217a10de3d5e
Author: Eric Blake <ebb9@...>
Date: Tue Oct 20 08:30:03 2009 -0600

Fix AC_TYPE_UINT64_T on Tru64 with gcc 3.4.4.

* lib/autoconf/types.m4 (_AC_TYPE_UNSIGNED_INT_BODY)
(_AC_TYPE_INT_BODY): Avoid undefined behavior of attempting shift
wider than type.
* NEWS: Document this.
Reported by Rainer Orth.

I think we need to start comparing test results against tables for at
least a couple of systems, in order to guard against such issues.

Cheers,
Ralf

From forum: Gnu - Autoconf - Bugs

Re: Dereference of undefined pointer value in conftest.c

2009-12-07T16:25:58Z

Hello Tomas,

* Tomas Carnecky wrote on Mon, Dec 07, 2009 at 10:00:43AM CET:

> On Dec 7, 2009, at 7:36 AM, Ralf Wildenhues wrote:
> > Last time we looked at this code because someone reported oddities, we
> > concluded that we shouldn't change the test because we had no way of
> > verifying whether the test would still expose the documented issue
> > afterwards. In general, you are of course right that tests shouldn't
> > have undefined behavior, but sometimes that is unavoidable.
>
> I see. It was interesting to run the configure script through clang
> and see which warnings it would generate. I'll just ignore those in
> the future.

Actually, I think it would make sense to have them reported and
annotated in the macros somehow. After all, they could be actual bugs.

I'm not sure whether it is useful to use annotations of a specific
analysis tool like clang; one alternative would be to just note it in
the comments before the macro.

So if you care about this, here's a suggestion: run the full Autoconf
test suite with TESTSUITEFLAGS='-d CC=...clang' to keep the test
directories and with CC suitably set for analysis. Then let's examine
the results. (If you choose not to do this, I can do it too, time
permitting.)

Thanks,
Ralf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: Dereference of undefined pointer value in conftest.c

2009-12-07T01:00:43Z

On Dec 7, 2009, at 7:36 AM, Ralf Wildenhues wrote:

> Hello Tomas,
>
> * Tomas Carnecky wrote on Sun, Dec 06, 2009 at 09:10:47PM CET:
>> I just ran the clang static analyzer on the xserver configure script and
>> it reported a few issues. Most of them were dead assignments/increments,
>> but there also was one dereference of an undefined pointer value. I
>> don't know which tests the conftest.c belongs to, but I doubt it's to
>> test if an application can safely write to unknown memory ;). The test
>> contains the following code:
>
> The code is from AC_C_CONST. If your package requires anything near a
> C89 (or newer) compiler, then you don't need and shouldn't use
> AC_C_CONST. Compilers not grokking 'const' are old (I don't know how
> old, but I've never met one).
>
> Last time we looked at this code because someone reported oddities, we
> concluded that we shouldn't change the test because we had no way of
> verifying whether the test would still expose the documented issue
> afterwards. In general, you are of course right that tests shouldn't
> have undefined behavior, but sometimes that is unavoidable.

I see. It was interesting to run the configure script through clang and see which warnings it would generate. I'll just ignore those in the future.

tom

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: Dereference of undefined pointer value in conftest.c

2009-12-06T22:36:49Z

Hello Tomas,

* Tomas Carnecky wrote on Sun, Dec 06, 2009 at 09:10:47PM CET:
> I just ran the clang static analyzer on the xserver configure script and
> it reported a few issues. Most of them were dead assignments/increments,
> but there also was one dereference of an undefined pointer value. I
> don't know which tests the conftest.c belongs to, but I doubt it's to
> test if an application can safely write to unknown memory ;). The test
> contains the following code:

The code is from AC_C_CONST. If your package requires anything near a
C89 (or newer) compiler, then you don't need and shouldn't use
AC_C_CONST. Compilers not grokking 'const' are old (I don't know how
old, but I've never met one).

Last time we looked at this code because someone reported oddities, we
concluded that we shouldn't change the test because we had no way of
verifying whether the test would still expose the documented issue
afterwards. In general, you are of course right that tests shouldn't
have undefined behavior, but sometimes that is unavoidable.

Cheers,
Ralf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: Dereference of undefined pointer value in conftest.c

2009-12-06T18:27:50Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ruben Safir on 12/6/2009 7:15 PM:

> On Sun, Dec 06, 2009 at 09:10:47PM +0100, Tomas Carnecky wrote:
>> I just ran the clang static analyzer on the xserver configure script and
>> it reported a few issues. Most of them were dead assignments/increments,
>> but there also was one dereference of an undefined pointer value. I
>> don't know which tests the conftest.c belongs to, but I doubt it's to
>> test if an application can safely write to unknown memory ;). The test
>> contains the following code:
>>
>> { /* SCO 3.2v4 cc rejects this. */
>> char *t;
>> char const *s = 0 ? (char *) 0 : (char const *) 0;
>> *t++ = 0; /* <<< t is undefined! */
>> if (s) return 0;
>> }
>>
>> Tell me if you want more informations or if you are interested in the
>> full report from clang.
>>
>> tom
>>
>
>
> This whole piece of code looks screwed up to me. Why would a trinary
> operator try to return anonymous nulls?

Both of you are missing the point of this test.

$ git grep -B30 't\+\+ = 0'

shows that it is part of:

> lib/autoconf/c.m4-AC_DEFUN([AC_C_CONST],
> lib/autoconf/c.m4-[AC_CACHE_CHECK([for an ANSI C-conforming const], ac_cv_c_const,
> lib/autoconf/c.m4-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],

in other words, it is a compile-only test, to see if the compiler supports
a compliant implementation of const. The code in question will never be
run, so a ternary operator returning NULL, or dead code, or even
dereferencing uninitialized variables, don't matter. All that matters is
that the compiler is properly type-safe and properly honors const.

That said, if there are some simple things we can to do to make various
compilers less likely to complain about suspicious concepts while still
getting correct answers about detecting broken compilers, then propose a
patch. But for now, I'm not worried about changing anything.

- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkscaCYACgkQ84KuGfSFAYCmaACfRgyFPRI6qnUcN/EIW4R04VVu
IWIAoMmuAe9xhHD2g3Y/hUj0WTUI13ft
=7i3k
-----END PGP SIGNATURE-----

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: Dereference of undefined pointer value in conftest.c

2009-12-06T18:15:18Z

On Sun, Dec 06, 2009 at 09:10:47PM +0100, Tomas Carnecky wrote:

> I just ran the clang static analyzer on the xserver configure script and
> it reported a few issues. Most of them were dead assignments/increments,
> but there also was one dereference of an undefined pointer value. I
> don't know which tests the conftest.c belongs to, but I doubt it's to
> test if an application can safely write to unknown memory ;). The test
> contains the following code:
>
> { /* SCO 3.2v4 cc rejects this. */
> char *t;
> char const *s = 0 ? (char *) 0 : (char const *) 0;
> *t++ = 0; /* <<< t is undefined! */
> if (s) return 0;
> }
>
> Tell me if you want more informations or if you are interested in the
> full report from clang.
>
> tom
>

This whole piece of code looks screwed up to me. Why would a trinary
operator try to return anonymous nulls?

Ruben

>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@...
> http://lists.gnu.org/mailman/listinfo/autoconf

--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Dereference of undefined pointer value in conftest.c

2009-12-06T12:10:47Z

I just ran the clang static analyzer on the xserver configure script and
it reported a few issues. Most of them were dead assignments/increments,
but there also was one dereference of an undefined pointer value. I
don't know which tests the conftest.c belongs to, but I doubt it's to
test if an application can safely write to unknown memory ;). The test
contains the following code:

{ /* SCO 3.2v4 cc rejects this. */
char *t;
char const *s = 0 ? (char *) 0 : (char const *) 0;
*t++ = 0; /* <<< t is undefined! */
if (s) return 0;
}

Tell me if you want more informations or if you are interested in the
full report from clang.

tom

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: GNU Make -v output no longer includes "version"

2009-12-06T05:08:38Z

On Sun, Dec 6, 2009 at 8:52 UTC, Ralf Wildenhues wrote:
> Thanks for reporting this; but you have arrived at the wrong place to
> report it: while this code comes from an Autoconf macro, it doesn't
> come from Autoconf itself; presumably it's from a macro shipping with
> ntp.

Yes, it comes from the main configure.ac of NTP. Apologies for the
noise, I had incorrectly assumed it was coming from Automake or
Autoconf since it didn't make sense to me that NTP would have both the
NTP_VPATH_HACK macro in m4/ntp_vpathhack.m4 and a different snippet
also dealing with VPATH elsewhere, but we do.

Thanks for the quick response,
Dave Hart

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: GNU Make -v output no longer includes "version"

2009-12-06T00:52:53Z

Hello Dave,

* Dave Hart wrote on Sun, Dec 06, 2009 at 07:38:30AM CET:
> Having fixed a similar bug in a NTP-local NTP_VPATH_HACK macro, the
> following snippet jumped out at me in a configure script from
> ntp-4.2.5p250-RC generated with Autoconf 2.65:

Thanks for reporting this; but you have arrived at the wrong place to
report it: while this code comes from an Autoconf macro, it doesn't
come from Autoconf itself; presumably it's from a macro shipping with
ntp. You need to report this to the ntp maintainers. You can notify
the GNU make list (bug-make at gnu.org), but my guess is that their
--version output was just changed to conform to GNU Coding Standards so
they are unlikely to undo that.

Hope that helps.

Cheers,
Ralf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

GNU Make -v output no longer includes "version"

2009-12-05T22:38:30Z

Having fixed a similar bug in a NTP-local NTP_VPATH_HACK macro, the
following snippet jumped out at me in a configure script from
ntp-4.2.5p250-RC generated with Autoconf 2.65:

case "$ac_busted_vpath_in_make$srcdir" in
no*) ;;
yes.) ;;
*) case "`${MAKE-make} -v -f /dev/null 2>/dev/null | sed -e 's/GNU
Make version $1-9.]*$.*/\1/' -e q`" in
'')
as_fn_error "building outside of the main directory requires
GNU make" "$LINENO" 5
;;
*) ;;
esac
;;
esac

Note that GNU Make doesn't include the word "version" in -v output
anymore, apparently:

hart@psp-fb2> gmake -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-portbld-freebsd6.4
hart@psp-fb2>

So I'd suggest removing it from the sed expression above.

Cheers,
Dave Hart

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: license in generated files

2009-12-05T14:10:06Z

Ralf Wildenhues wrote:

> Well, if you merge together portions with different copyrights, wasn't
> it ok to just list the copyright statements one after the other, with
> some indication on what covers what?

Yes, that’s true. A stickler for details might note that the current
notice says “This Makefile.in is free software”, which is not always the
case.

>> karl@... (Karl Berry) writes:

>>> 2) [More important.] How about having autoheader add the same statement
>>> to config.in?
>
> Sounds like a good idea, although the amount of copyrightable content is
> pretty limited there (thinking of original content, not just pure number
> of lines).

Doesn’t the copyright (and license) apply to documentation as well? At
least this was enough to get me to track down the origin of the comments
in one long config.h to make sure it all came from autoconf.

Though it is probably unnecessary, I would be happy to see a notice.

Thanks also for pointing out AC_COPYRIGHT; I hadn’t known about that.

Kind regards,
Jonathan

From forum: Gnu - Autoconf - Bugs

Re: testsuite.log

2009-12-05T06:25:07Z

Hello Karl,

thanks for the report.

* Karl Waern wrote on Sat, Dec 05, 2009 at 12:42:47AM CET:
> There was an admonition to send this along; don't know enough about
> this to have any other information which might help, but hopefully
> this is of some help!

This is the information about the failing test:

> 34. tools.at:1127: testing ...
> ./tools.at:1133: automake --version || exit 77
> stderr:
> stdout:
> automake (GNU automake) 1.10
[...]

> ./tools.at:1134: test ! -f $HOME/.autom4te.cfg || exit 77
> stderr:
> stdout:
> ./tools.at:1151: aclocal || { ret=$?; test $ret -eq 63 && ret=77; exit $ret; }
> stderr:
> ./tools.at:1152: test -d autom4te.cache || exit 77
> ./tools.at:1153: autoconf
> --- /dev/null 2009-12-04 15:17:40.000000000 -0800
> +++ /Users/kmw47/Downloads/autoconf-2.65/tests/testsuite.dir/at-groups/34/stderr 2009-12-04 15:17:40.000000000 -0800
> @@ -0,0 +1,5 @@
> +aclocal.m4:17: error: this file was generated for autoconf 2.61.
> +You have another version of autoconf. If you want to use that,
> +you should regenerate the build system entirely.
> +aclocal.m4:17: the top level
> +autom4te: /usr/bin/m4 failed with exit status: 63
> ./tools.at:1153: exit code was 63, expected 0
> 34. tools.at:1127: 34. autom4te preselections (tools.at:1127): FAILED (tools.at:1153)

Hmm. That's weird. Have you built and installed Automake yourself, and
if yes, where? Do you have the environment variable $AUTOM4TE set to
some value?

aclocal should be picking up the autom4te program from the tests
directory.

Thanks,
Ralf

From forum: Gnu - Autoconf - Bugs

Re: testsuite: fixed spurious failure in vala4.test (w.r.t. Solaris sh)

2009-12-05T04:39:28Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 12/5/2009 5:23 AM:
> That was a pretty bad failure, with the example not matching the
> description at all. Next try. OK?

The second spin is okay (and I'm embarrassed about the obvious typo fix).

- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksaVIQACgkQ84KuGfSFAYBRCgCfZu4tnr9B0xF3UwocWA/3nIVS
8M0AoKrqaYY4ffy/GGhgNXcYVfJTNZbF
=0cIH
-----END PGP SIGNATURE-----

From forum: Gnu - Autoconf - Patches

Re: testsuite: fixed spurious failure in vala4.test (w.r.t. Solaris sh)

2009-12-05T04:23:59Z

* Ralf Wildenhues wrote on Sat, Dec 05, 2009 at 01:02:58PM CET:
> [ adding autoconf-patches; this is
> <http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3698> ]
>
> Proposed patch for Autoconf. OK?

That was a pretty bad failure, with the example not matching the
description at all. Next try. OK?

commit 3efa7027f91c0f232c5b4bafba1ffd415a58cde8
Author: Stefano Lattarini <stefano.lattarini@...>
Date: Sat Dec 5 12:56:30 2009 +0100

Document Solaris/Heirloom sh set -e issue with command substitutions.

* doc/autoconf.texi (Limitations of Builtins): Fix typos `set -d'
in previous example. Document failure to honor && lists with set -e
and a command substitution in the failing command.
Report and initial patch by Stefano Lattarini against Automake.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@...>

diff --git a/ChangeLog b/ChangeLog
index e03604d..1c0c612 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-12-05 Stefano Lattarini <stefano.lattarini@...>
+ Ralf Wildenhues <Ralf.Wildenhues@...>
+
+ Document Solaris/Heirloom sh set -e issue with command substitutions.
+ * doc/autoconf.texi (Limitations of Builtins): Fix typos `set -d'
+ in previous example. Document failure to honor && lists with set -e
+ and a command substitution in the failing command.
+ Report and initial patch by Stefano Lattarini against Automake.
+
2009-12-04 Eric Blake <ebb9@...>

Warn if using unnamed diversion.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7d2c72e..3144610 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16794,12 +16794,23 @@ Limitations of Builtins
Solaris @command{/bin/sh} cannot be ignored, even with @samp{||}.

@example
-$ @kbd{/bin/sh -c 'set -d; foo=`false` || echo foo; echo bar'}
-$ @kbd{bash -c 'set -d; foo=`false` || echo foo; echo bar'}
+$ @kbd{/bin/sh -c 'set -e; foo=`false` || echo foo; echo bar'}
+$ @kbd{bash -c 'set -e; foo=`false` || echo foo; echo bar'}
foo
bar
@end example

+@noindent
+Moreover, a command substitution, successful or not, causes this shell to
+exit from a failing outer command even in presence of an @samp{&&} list:
+
+@example
+$ @kbd{bash -c 'set -e; false `true` && echo notreached; echo ok'}
+ok
+$ @kbd{sh -c 'set -e; false `true` && echo notreached; echo ok'}
+$
+@end example
+
Portable scripts should not use @samp{set -e} if @command{trap} is used
to install an exit handler. This is because Tru64/OSF 5.1 @command{sh}
sometimes enters the trap handler with the exit status of the command

From forum: Gnu - Autoconf - Patches

Re: testsuite: fixed spurious failure in vala4.test (w.r.t. Solaris sh)

2009-12-05T04:02:58Z

[ adding autoconf-patches; this is
<http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3698> ]

Proposed patch for Autoconf. OK?

Thanks,
Ralf

commit 4f89a570c7ccb07237d4a698a4e60db507880be0
Author: Stefano Lattarini <stefano.lattarini@...>
Date: Sat Dec 5 12:56:30 2009 +0100

Document Solaris/Heirloom sh set -e issue with command substitutions.

* doc/autoconf.texi (Limitations of Builtins): Fix typos `set -d'
in previous example. Document failure to honor && lists with set -e
and a command substitution in the failing command.
Report and initial patch by Stefano Lattarini against Automake.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@...>

diff --git a/ChangeLog b/ChangeLog
index e03604d..1c0c612 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-12-05 Stefano Lattarini <stefano.lattarini@...>
+ Ralf Wildenhues <Ralf.Wildenhues@...>
+
+ Document Solaris/Heirloom sh set -e issue with command substitutions.
+ * doc/autoconf.texi (Limitations of Builtins): Fix typos `set -d'
+ in previous example. Document failure to honor && lists with set -e
+ and a command substitution in the failing command.
+ Report and initial patch by Stefano Lattarini against Automake.
+
2009-12-04 Eric Blake <ebb9@...>

Warn if using unnamed diversion.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7d2c72e..b25f165 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16794,12 +16794,21 @@ Limitations of Builtins
Solaris @command{/bin/sh} cannot be ignored, even with @samp{||}.

@example
-$ @kbd{/bin/sh -c 'set -d; foo=`false` || echo foo; echo bar'}
-$ @kbd{bash -c 'set -d; foo=`false` || echo foo; echo bar'}
+$ @kbd{/bin/sh -c 'set -e; foo=`false` || echo foo; echo bar'}
+$ @kbd{bash -c 'set -e; foo=`false` || echo foo; echo bar'}
foo
bar
@end example

+@noindent
+Moreover, a command substitution, successful or not, causes this shell to
+exit from a failing outer command even in presence of an @samp{&&} list:
+
+@example
+$ @kbd{/bin/sh -c 'set -e; false `true` || echo did not exit'}
+$
+@end example
+
Portable scripts should not use @samp{set -e} if @command{trap} is used
to install an exit handler. This is because Tru64/OSF 5.1 @command{sh}
sometimes enters the trap handler with the exit status of the command

From forum: Gnu - Autoconf - Patches

Re: license in generated files

2009-12-05T02:46:33Z

* Russ Allbery wrote on Sat, Dec 05, 2009 at 12:42:22AM CET:

> karl@... (Karl Berry) writes:
>
> > This is really split between autoconf and automake, but I'll just write
> > here for now.
>
> > 1) The license statement added in Makefile.in starts:
> > ..
> > # This Makefile.in is free software; the Free Software Foundation
>
> > But then it is copied into the Makefile too, so it's no longer the
> > "Makefile.in". How about "This file", or "This Makefile" -- seems
> > sufficiently generic to me to cover the Makefile.in too? Or I suppose
> > autoconf could add yet another statement "This Makefile is free ...".

But the license concerns Makefile.in only, since the Makefile is never
distributed, no?

> It's also not necessarily true if the Makefile.am is covered under some
> other license, since the Makefile.in (and the Makefile) is a derived work
> of both Automake and the Makefile.am. If the boilerplate is modified,
> maybe it should also be more specific about saying that this license only
> covers the portions that come from Automake?

Well, if you merge together portions with different copyrights, wasn't
it ok to just list the copyright statements one after the other, with
some indication on what covers what? Autoconf allows adding copyright
statements to configure scripts with AC_COPYRIGHT (AT_COPYRIGHT for
testsuites), and automake adds single-# comments from the top of the
Makefile.am and from the top of 'include'd fragments to near the top of
the Makefile.in file. As far as I'm concerned, that seems sufficient.

As far as clarity is concerned, well, it might be improved as you state
above. As far as a lawyerese answer is needed, I've emailed Brett a
while ago anyway for updating Automake to GPLv3 (plus exceptions), where
things have progressed a bit since but are not done yet, that might be a
good opportunity to ask about this as well.

> > 2) [More important.] How about having autoheader add the same statement
> > to config.in?

Sounds like a good idea, although the amount of copyrightable content is
pretty limited there (thinking of original content, not just pure number
of lines).

Cheers,
Ralf

From forum: Gnu - Autoconf - Bugs

Re: divert()/m4_divert() broken in autoconf-2.64+

2009-12-04T20:17:57Z

According to Eric Blake on 11/28/2009 2:56 PM:
> At any rate, here's the patch I'm currently testing, to issue a syntax
> warning when not using a named diversion, and to document the fallout from
> this thread.

Testing didn't reveal any uses in libtool or gnulib that used unnamed
diversions (and both of them do have instances of using named diversions).
Now pushed, with a test squashed in:

diff --git a/ChangeLog b/ChangeLog
index 5edb895..e03604d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,4 @@
-2009-11-30 Eric Blake <ebb9@...>
+2009-12-04 Eric Blake <ebb9@...>

Warn if using unnamed diversion.
* lib/m4sugar/m4sugar.m4 (_m4_divert, m4_divert_push): Add
@@ -7,11 +7,13 @@
(_m4_require_call): Adjust callers.
* lib/m4sugar/m4sh.m4 (AS_REQUIRE): Likewise.
* tests/m4sh.at (AT_DATA_LINENO): Avoid triggering the warning.
- * tests/tools.at (autom4te and whitespace in file names)
- (autoconf: the empty token): Likewise.
* tests/m4sugar.at (AT_CHECK_M4SUGAR_TEXT, m4@&t@_append)
(m4@&t@_text_wrap, recursion): Likewise.
(m4@&t@_warn, m4@&t@_divert_stack): Adjust expected output.
+ * tests/tools.at (autom4te and whitespace in file names)
+ (autoconf: the empty token): Avoid triggering the warning.
+ (autoconf: AC_PRESERVE_HELP_ORDER): New test.
+ * tests/mktests.sh (ac_exclude_list): Retire prior test.
* NEWS: Document the warning.
* doc/autoconf.texi (Redefined M4 Macros) <m4_divert>,
<m4_undivert>: Make even more explicit that using these directly
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index c9e570d..7d2c72e 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -11409,9 +11409,10 @@ Diversion support
early enough in @file{configure} that it is unsafe to expand any
autoconf macros into this diversion.
@item HELP_ENABLE
-If @code{AC_PRESERVE_HELP_ORDER} was used, then it is safe to use
-@code{AS_ECHO} in this diversion to insert additional text into the
-@option{--help} output of @file{configure}.
+If @code{AC_PRESERVE_HELP_ORDER} was used, then text placed in this
+diversion will be included as part of a quoted here-doc providing all of
+the @option{--help} output of @file{configure} related to options
+created by @code{AC_ARG_WITH} and @code{AC_ARG_ENABLE}.
@item INIT_PREPARE
This diversion occurs after all command line options have been parsed,
but prior to the main body of the @file{configure} script. This
diff --git a/tests/mktests.sh b/tests/mktests.sh
index d44d6b9..9897599 100755
--- a/tests/mktests.sh
+++ b/tests/mktests.sh
@@ -138,6 +138,9 @@ ac_exclude_list='

# Already tested by AT_CHECK_MACRO.
/^AC_OUTPUT$/ {next}
+
+ # Tested alongside m4_divert_text.
+ /^AC_PRESERVE_HELP_ORDER$/ {next}
'

diff --git a/tests/tools.at b/tests/tools.at
index 751975f..aa3f258 100644
--- a/tests/tools.at
+++ b/tests/tools.at
@@ -535,6 +535,41 @@ AT_CLEANUP

+# autoconf: AC_PRESERVE_HELP_ORDER
+# --------------------------------
+AT_SETUP([autoconf: AC_PRESERVE_HELP_ORDER])
+AT_KEYWORDS([m4@&t@_divert_text])
+
+AT_DATA_AUTOCONF([configure.ac],
+[[AC_INIT
+AC_PRESERVE_HELP_ORDER
+AC_ARG_WITH([one], [ --with-one])
+AC_ARG_ENABLE([two], [ --enable-two])
+m4_divert_text([HELP_ENABLE], [arbitrary $text])
+AC_ARG_WITH([three], [ --with-three])
+AC_OUTPUT
+]])
+
+AT_CHECK_AUTOCONF
+AT_CHECK_CONFIGURE([--help], [], [stdout])
+AT_CHECK([sed -n '/^Optional/,/^$/p' stdout], [],
+[[Optional Features and Packages:
+ --disable-option-checking ignore unrecognized --enable/--with options
+ --disable-FEATURE do not include FEATURE (same as
--enable-FEATURE=no)
+ --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
+ --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
+ --with-one
+ --enable-two
+arbitrary $text
+ --with-three
+
+]])
+
+AT_CLEANUP
+
+
+
## --------- ##
## ifnames. ##
## --------- ##

--
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...

signature.asc (329 bytes) Download Attachment

From forum: Gnu - Autoconf - Patches

testsuite.log

2009-12-04T15:42:47Z

There was an admonition to send this along; don't know enough about this to have any other information which might help, but hopefully this is of some help!

-Karl

testsuite.log (50K) Download Attachment

From forum: Gnu - Autoconf - Bugs

Re: license in generated files

2009-12-04T15:42:22Z

karl@... (Karl Berry) writes:

> This is really split between autoconf and automake, but I'll just write
> here for now.

> 1) The license statement added in Makefile.in starts:
> ..
> # This Makefile.in is free software; the Free Software Foundation

> But then it is copied into the Makefile too, so it's no longer the
> "Makefile.in". How about "This file", or "This Makefile" -- seems
> sufficiently generic to me to cover the Makefile.in too? Or I suppose
> autoconf could add yet another statement "This Makefile is free ...".

It's also not necessarily true if the Makefile.am is covered under some
other license, since the Makefile.in (and the Makefile) is a derived work
of both Automake and the Makefile.am. If the boilerplate is modified,
maybe it should also be more specific about saying that this license only
covers the portions that come from Automake?

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

From forum: Gnu - Autoconf - Bugs

license in generated files

2009-12-04T15:21:46Z

This is really split between autoconf and automake, but I'll just write
here for now.

1) The license statement added in Makefile.in starts:
..
# This Makefile.in is free software; the Free Software Foundation

But then it is copied into the Makefile too, so it's no longer the
"Makefile.in". How about "This file", or "This Makefile" -- seems
sufficiently generic to me to cover the Makefile.in too? Or I suppose
autoconf could add yet another statement "This Makefile is free ...".

2) [More important.] How about having autoheader add the same statement
to config.in?

Thanks,
k

From forum: Gnu - Autoconf - Bugs

Re: C99 inline and restrict keyword tests

2009-12-03T04:53:11Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 12/2/2009 2:48 PM:

>>>> Testing for "inline" and "restrict" keywords is redundant,
>>>> eg, checking ac_cv_prog_cc_c99 = yes should be enough.
>>> Well, in theory you are right.
>> Hey, autoconf is here to help developer to workaround reality and
>> stay in the theory nirvana :)
>
> I'd guess not. B.11.11.20 is not found as compatible with
> AC_INIT
> AC_PROG_CC_C99
>
> due to:
> configure:2799: cc -AC99 -c -g conftest.c >&5
> cc: "conftest.c", line 58: error 1671: Illegal use of restrict.
> configure:2806: $? = 1
>
> but with
> AC_INIT
> AC_PROG_CC
> AC_C_RESTRICT
> AC_PROG_CC_C99
>
> -AC99 will get turned on, and restrict #define'd to empty. Hmm, not
> very consistent, I guess.

I'm not too enthusiastic about changing the macro behavior; so it seems
like improving the documentation to better describe the current situation
seems like the way to go.

>> Should such compiler be rejected as C99 compliant C compiler ?.
>
> This is somewhat of a judgement call. If the bug is remote, then I
> don't think that a general macro like AC_PROG_CC_C99 should reject the
> compiler. In practice that will harm more users than help, because it
> will cause the necessary flag to enable C99 mode to not be used, which
> would have been sufficient for the bulk of uses.

Another instance of this is handling of 64-bit preprocessor constants. At
one point, we tried to make long long checking fail if the preprocessor
also mishandled things, but in practice, there were enough existing
compilers that could do everything except preprocessing correctly that we
changed things to just document that AC_PROG_CC_C99 no longer guarantees a
compliant preprocessor, and that it is unportable to use any proprocessing
constant that requires more than 32 bits while expecting correct
signedness treatment.

>> But the test stay like they are, if a note is added in AC_PROG_CC_C99,
>> such as:
>>
>> "AC_PROG_CC_C99 does not guarantee individual C99 features availability.
>> Some compiler don't implement some or have buggy implementation, so one
>> should use tests such as AC_C_INLINE, AC_C_RESTRICT, etc. in order to
>> check C99 features they rely on".
>
> This certainly would be one possibility.

Would either of you mind writing this up as a formal patch against
doc/autoconf.texi?

- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksXtLcACgkQ84KuGfSFAYDKcgCgtf1W9jXWxxx/qM2wWh00Cnai
k3gAoItu07rZ/4W328TeblAD2mBregtl
=uqr2
-----END PGP SIGNATURE-----

From forum: Gnu - Autoconf - Bugs

Re: pkglibdir vs. lib64

2009-12-03T01:45:24Z

Alfred M. Szmidt wrote:
> A diligent distro package maintainer certainly reads the
> Makefile.am, and also reviews the full diff between upstream
> releases.
>
> Very few packages do this,

I don't think that anyone can state with reasonable certainty how many
do or do not do this. I do it for all packages I maintain, and I know
other maintainers who adhere to the same practice. OTOH, there are
surely people who don't bother.

> and it is immensly unfeasible for them to do so.

It is, especially for large packages. But those who are afraid of
wolves shouldn't walk in the woods.

> It is like asking a user to look through the diff before
> installing a new version of a program.

No, there's a HUGE difference. What you do as a user concerns you and
only you. What you do as a maintainer affects others.

As an upstream maintainer, you don't just collect and recklessly
commit patches, releasing the havoc afterwards, right? You review
them carefully, you excercise human judgement to the best of your
knowledge and ability, and the release you make is something you could
wholeheartedly recommend to users.

Similarly, a distro package maintainer is responsible for many users
and it's simply not acceptable to maintain a package without a certain
degree of involvement and judgement. That's why maintainers are
humans and not packaging bots (there are some who behave like bots,
perhaps).

But this is getting off-topic. My point was that a comment in a
Makefile.am (as suggested by the OP) should be spotted by a *decent*
maintainer, as maintainers *usually* pay attention to changes,
especially changes in the build system. (Mike is also right that
distro maintainers are well aware of this particular issue.)

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: autoconf vs

2009-12-02T22:33:57Z

* Erik de Castro Lopo wrote on Wed, Dec 02, 2009 at 10:33:05PM CET:
> However, one I sort out the problems above, it still doesn't explain
> why:
>
> AC_CHECK_HEADER([cstdint])
>
> does result in a HAVE_CSTDINT getting added to the config.h file.

We'd need to see the respective parts of config.log to be able to help.

Cheers,
Ralf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: C99 inline and restrict keyword tests

2009-12-02T13:48:37Z

* Yann Droneaud wrote on Wed, Dec 02, 2009 at 10:32:26AM CET:

> Le mardi 01 décembre 2009 à 19:25 +0100, Ralf Wildenhues a écrit :
> > * Yann Droneaud wrote on Tue, Dec 01, 2009 at 03:09:11PM CET:
> > > If AC_PROG_CC_C99 successfully found a C99 compliant C compiler,
> > > AC_C_INLINE and AC_C_RESTRICT should use this result.
> > >
> > > Testing for "inline" and "restrict" keywords is redundant,
> > > eg, checking ac_cv_prog_cc_c99 = yes should be enough.
> >
> > Well, in theory you are right.
>
> Hey, autoconf is here to help developer to workaround reality and
> stay in the theory nirvana :)

> > In practice, the restrict macro tries to
> > get a spelling that is likely to be accepted by the C++ compiler as
> > well, and the inline case checks for a specific compiler bug:
> >
> > # HP C version B.11.11.04 doesn't allow a typedef as the return value for an
> > # inline function, only builtin types.
> >
> > I can only check B.11.11.20, and it does not seem to have that bug (any
> > more).
>
> Is HP C version B.11.11.04 found as C99 compatible by AC_PROG_CC_C99 ?

I'd guess not. B.11.11.20 is not found as compatible with
AC_INIT
AC_PROG_CC_C99

due to:
configure:2799: cc -AC99 -c -g conftest.c >&5
cc: "conftest.c", line 58: error 1671: Illegal use of restrict.
configure:2806: $? = 1

but with
AC_INIT
AC_PROG_CC
AC_C_RESTRICT
AC_PROG_CC_C99

-AC99 will get turned on, and restrict #define'd to empty. Hmm, not
very consistent, I guess.

> AC_PROG_CC_C99 use a test with one inline and one restrict, but not the
> corner case about typedef'ed type.
>
> Should such compiler be rejected as C99 compliant C compiler ?.

This is somewhat of a judgement call. If the bug is remote, then I
don't think that a general macro like AC_PROG_CC_C99 should reject the
compiler. In practice that will harm more users than help, because it
will cause the necessary flag to enable C99 mode to not be used, which
would have been sufficient for the bulk of uses.

But in the end, this is the maintainer's call. The documentation should
be updated in either outcome, to reflect the actual semantics of the
macros.

> IMHO, AC_PROG_CC_C99 and AC_C_INLINE + AC_C_RESTRICT should be related
> in some ways, perhaps AC_PROG_CC_C99 should rely on AC_C_INLINE +
> AC_C_RESTRICT ?
> In my first post, I was proposing the opposite: AC_C_INLINE +
> AC_C_RESTRICT relying of AC_PROG_CC_C99 result.
>
> But the test stay like they are, if a note is added in AC_PROG_CC_C99,
> such as:
>
> "AC_PROG_CC_C99 does not guarantee individual C99 features availability.
> Some compiler don't implement some or have buggy implementation, so one
> should use tests such as AC_C_INLINE, AC_C_RESTRICT, etc. in order to
> check C99 features they rely on".

This certainly would be one possibility.

Cheers,
Ralf

From forum: Gnu - Autoconf - Bugs

Re: autoconf vs

2009-12-02T13:33:05Z

Ralf Wildenhues wrote:

> The easiest user workaround for this is to
> ./configure CXX="g++ -std=gnu++0x"

Unfortunately this wont work as the code needs to be built by an autobuilder
on two different systems, one with a g++ that requires -std=gnu++0x and the
other which doesn't understand -std=gnu++0x. I'd prefer not to have to hack
a workaround for this into the autobuilder.

> Of course, -Werror is problematic in many cases, but here it's not the
> cause.

I've moved the test for <cstdint> to a place before -Werror is added.

> The bug is in the AC_ADD_CXXFLAGS macro (which, by the way, is not from
> Autoconf so its name shouldn't start with 'AC_')

Noted.

> or your usage thereof:
> AC_ADD_CXXFLAGS([-std=gnu++0x])
>
> because the flag does not just influence the C++ compiler but also its
> preprocessor. As developer, you could use AC_PROG_CXXCPP and adjust
> $CXXCPP to also contain -std=gnu++0x when it is deemed acceptable (I
> suppose AC_ADD_CXXFLAGS has an optional IF-OK argument?).

No. This was a macro I picked up from somewhere else. Looks like I'll
have to hack it a bit.

However, one I sort out the problems above, it still doesn't explain
why:

AC_CHECK_HEADER([cstdint])

does result in a HAVE_CSTDINT getting added to the config.h file.

Regards,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General

Re: question about using AC_SEARCH_LIBS with fortran...

2009-12-02T12:05:10Z

* Ed Hartnett wrote on Wed, Dec 02, 2009 at 06:41:08PM CET:
> Before I continue asking questions about my fortran AC_SEARCH_LIBS
> question, let me first make sure I've got it correct for my C library,
> because I just recently realized that I've been doing it wrong for
> years.

No, you haven't.

> In my libcf configure.ac file I have added the following:
>
> AC_SEARCH_LIBS([deflate], [z])
> AC_SEARCH_LIBS([ceil], [m])
> AC_SEARCH_LIBS([H5open], [hdf5])
> AC_SEARCH_LIBS([H5DSattach_scale], [hdf5_hl])
> AC_SEARCH_LIBS([Curl_cfree], [curl])
> AC_SEARCH_LIBS([nc_open], [netcdf])
>
> This finds all the correct libraries in the correct order, and helpfully
> adds them to the LIBS variable, so that I don't have to have things like
> this in my makefile:
>
> if USE_NETCDF4
> LDADD += -lhdf5_hl -lhdf5 -lz
> endif
>
> This is wonderful, but how does the user pass in a special directory
> that may include his HDF5 library? With the CPPFLAGS and LDFLAGS,
> correct?

LDFLAGS, yes.

> Meanwhile I support in my configure script a way to specify a location
> for HDF5:
[...]
> AC_ARG_WITH([hdf5],
[...]
> AC_MSG_RESULT([$HDF5DIR])

This is a fine possibility as well.

> What I have been doing is handling all this in my Makefile.am files.
> But that will go away under the new (to me) system of using
> AC_SEARCH_LIBS properly.

Well, complex packages need both. In that case, it is typical to save
in LIBS all libraries that are needed by most or all programs in the
package, and use other variables (like HDF5_LIB, HDF5_INCLUDE or so)
for the rest. Both AC_CHECK_LIB and AC_SEARCH_LIBS allow you to store
their result in other variables as well, through the ACTION-IF-FOUND
arguments of the macros. One difference is that AC_SEARCH_LIBS always
updates $LIBS while AC_CHECK_LIB only does so if ACTION-IF-FOUND is not
given. If needed you can save and restore the $LIBS value to keep it
unchanged.

> But how to get the user's --with-hdf5=/somewhere option into the list of
> directories searched by AC_SEARCH_LIBS? Do I modify CPPFLAGS and LDFLAGS
> before calling AC_SEARCH_LIBS in my configure.ac?

Yes. The CPPFLAGS should be set before you search for headers.

> Or is there some other
> way to tell AC_SEARCH_LIBS to add another directory to search for the
> library?

No.

Cheers,
Ralf

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

From forum: Gnu - Autoconf - General