Bug triage for 2.72 complete; release freeze begins now

[Zack Weinberg]

Bug triage for 2.72 is complete.  All bug-autoconf subscribers, thank
you for your patience with the flood of low-information email.

I intend to make the final release of 2.72 no sooner than Monday, Dec.
18, but no *later* than Friday, Dec. 22.  Please consider the 'master'
branch to be in release freeze starting now: do not commit any patch to
'master' without first posting it to autoconf-patches and waiting for
me to OK it.

That said, please don't hesitate to tackle anything in the lists below,
even if it's not in the top two categories.

Testing is still extremely useful, especially testing on OSes other than
Linux, testing with development gcc and/or clang, and testing that goes
beyond autoconf's built-in test suite (e.g. pick your favorite project,
regenerate its configure script with trunk autoconf, and see if it still
probes everything correctly).

Here's the breakdown of all open bug reports, in decreasing order
of priority:

## Release blockers: 1 bug

* #110927: 30 tests fail building on macOS Venture 13.5.1 with Xcode 14.3.1

This is believed to have been fixed, but the fix needs testing.  I am
testing it right now on the GCC Compile Farm's macOS machine, but it's
running an older version of both the operating system (12.6) and of
Xcode (14.2).  If anyone is able to test with an OS that's a closer
match to the bug reporter's machine, please do.  (You just need to
check out the 'master' branch, bootstrap, and run the testsuite.
Note that you will need to install a current version of GNU M4 if
you haven't already.)

## Desirable for release: 7 bugs

* #110318: autoreconf: support libtoolize being named glibtoolize
* #110503: Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally 
required
* #110554: AC_CONFIG_HEADERS doesn't work properly for files with Windows 
line-endings
* #110561: autoconf: store autom4te request keys in sorted order
* #110713: Use __STDC__VERSION as first test for C99 compatibility (patch 
attached)
* #110872: m4_warn differs in various ways from its documentation
* #110971: busybox mkdir is misdetected

These all look easy, and many of them have patches from the reporter.
I plan to work through all of them over the next few days.

## Desirable for the release after this one: 13 bugs

* #110266 [Important]: Revert regression in Yacc support, and add Bison support
* #110286 [Important]: Make it possible to request a specific (non-latest) 
version of a language standard
* #109676 [Normal]: only one "checking whether the AC_LANG compiler works"
* #110347 [Normal]: Revise documentation of when configure enters 
cross-compilation mode.
* #110348 [Normal]: Simplify rules for when configure enters cross-compiling 
mode
* #108092 [Minor]: AC_PROG_GREP can select /usr/xpg4/bin/grep under Solaris 9 
but it doesn't support long lines
* #110416 [Minor]: documentation: ordering of basic macros?
* #110612 [Minor]: Re-exec of $as_myself chooses wrong configure script from 
PATH
* #110297 [Wish]: AC_PATH_PROG should accept a basename as an override
* #110382 [Wish]: Make confdefs.h idempotent vs compiler warnings
* #110394 [Wish]: Support optional use of the C++ compiler in AC_PROG_CXX (and 
similarly for other languages)
* #110431 [Wish]: AC_INIT should accept shell variable expansion in its 
arguments
* #110435 [Wish]: autoreconf: recognize when AM_ICONV is used without the rest 
of gettext

Currently I think all of these should be deferred to 2.73, but ideally
no *later* than 2.73.  If anyone thinks any of these should *not* be
deferred, please say so now.

## "To do eventually" and "blocked": 23 bugs

I don't expect any progress in the near future on any of these bugs
and I don't think we should commit to any time frame for them.
If you see something in these lists that you think should be addressed
in the near future, *and* you're prepared to tackle it yourself,
please speak up.

Whether a bug belongs in one or the other of these categories is
unfortunately somewhat fuzzy so I'm going to break them down
differently for this message.

* #110354: Parallel autotest produces mangled output on Solaris 10

I got dibs on this one. I plan to work on it early next year. But it
requires a complete overhaul of the parallel test driver and I don't
know how long it's going to take.

* #110300: configure >/dev/full does not fail promptly

May be easy, or may require an enormous amount of work.

* #110746: GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

Should be easy ... for someone who deeply understands Fortran and MPI.

* #110478: support for slibtool ans optional replacement for GNU libtool

This can't go anywhere until the slibtool project does a bunch more
work.  After that, the Automake project has to do a bunch of work.
We only get involved at the very end.

* #108879: Add m4_forbid_pattern for autoconf-archive macros
* #110212: Transform pkgdatadir using program-prefix and -suffix
* #110395: Makefile generated from Makefile

Bug triage for 2.72 release commencing

[Zack Weinberg]

This morning I'm going to triage all the bugs in Savannah for whether
they need to be fixed before the 2.72 release.  There will be a brief
flood of bug-related email.

I will be using the "priority" field in Savannah to categorize the bugs.
Here is a summary of the codes I'm using.  (I have also put this into
Savannah itself.)

1 - Blocked: We cannot proceed with work on this bug until something not
under our control happens, such as the submitter providing additional
information, or a change being made to a different piece of software.

2 - Eventually: We want to fix this bug eventually but we are not going
to commit to any particular timeline. Bugs in this category probably
require a great deal of work which no one has volunteered to do.

3 - Release N+1: This bug is not scheduled to be fixed in the very next
release, but we intend to get it done for the release after that.

4: do not use

5 - Unprioritized: This bug is new and nobody has looked at it yet.

6: do not use

7 - Release N (Desirable): This bug is scheduled to be fixed in the very
next release, but it might get bumped to the release after that if we
run out of time.

8 - Release N (Blocker): This bug *will* be fixed in the very next
release, even if that means we have to delay the release until we're
sure it's fixed.

9 - Hotfix: We need to put out a release as soon as possible just
because of this bug.

zw

Bug in AX_LIB_HDF5

[Harald Anlauf]

Hello,

when analyzing the output from `h5fc -show', which e.g. on my Linux
system is

  gfortran -I/usr/include -L/usr/lib64 -lhdf5hl_fortran -lhdf5_hl 
-lhdf5_fortran -lhdf5

one would like to put all options of type -Ldirectory into variable
HDF5_FLIBS (for the linking flags) instead of HDF5_FFLAGS (for the
compilation flags).

The attached trivial & obvious patch fixes this.

Feel free to use it.

Thanks,
Harald

From 9bb09588d99d119ca0b9adbf7e69f370daf1b9f5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 22 Feb 2022 16:25:27 +0100
Subject: [PATCH] AX_LIB_HDF5: fix derivation of compile and link flags for
 Fortran

When analyzing the output from `h5fc -show`, add options of type -Ldir to
HDF5_FLIBS, not to HDF5_FFLAGS.
---
 m4/ax_lib_hdf5.m4 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/m4/ax_lib_hdf5.m4 b/m4/ax_lib_hdf5.m4
index 074c2a8..6b913d7 100644
--- a/m4/ax_lib_hdf5.m4
+++ b/m4/ax_lib_hdf5.m4
@@ -88,7 +88,7 @@
 #   and this notice are preserved. This file is offered as-is, without any
 #   warranty.

-#serial 20
+#serial 21

 AC_DEFUN([AX_LIB_HDF5], [

@@ -280,8 +280,8 @@ HDF5 support is being disabled (equivalent to --with-hdf5=no).
 -I*) echo $HDF5_FFLAGS | $GREP -e "$arg" >/dev/null \
   || HDF5_FFLAGS="$HDF5_FFLAGS $arg"
   ;;#(
--L*) echo $HDF5_FFLAGS | $GREP -e "$arg" >/dev/null \
-  || HDF5_FFLAGS="$HDF5_FFLAGS $arg"
+-L*) echo $HDF5_FLIBS | $GREP -e "$arg" >/dev/null \
+  || HDF5_FLIBS="$HDF5_FLIBS $arg"
  dnl HDF5 installs .mod files in with libraries,
  dnl but some compilers need to find them with -I
  echo $HDF5_FFLAGS | $GREP -e "-I${arg#-L}" >/dev/null \
--
2.35.3

bug#59406: [Update install instruction for macOS] Update install instruction for macOS

[Karl Berry]

--- a/INSTALL
+++ b/INSTALL
+On macOS, users should not use the default perl, but manually install
+it from https://www.perl.org/get.html.

Thanks for the suggestion. I have a couple comments:

1) INSTALL is maintained in Autoconf, not Automake. I'll try to redirect
the bug.

2) Why? I know plenty of people using the mac perl ok for various things.
It is a big barrier to install a new perl. Not something to recommend
lightly.

3) Even if needed, in general, I feel doubtful that such a blanket and
time-sensitive statement should be made in INSTALL. I see INSTALL still
contains a couple of notes on "Particular systems", though two are
hardly used any more as far as I know (HP-UX and OSF/1), and the other
tidbits feel pretty old also. As a matter of practical usefulness, I
feel like INSTALL is better off being about system-independent
configuration, leaving system information for web pages or other places
that aren't so static. But it's not up to me.

4) Notwithstanding all the above, at the very least, I think any such
statement should say something specific about how the default perl fails.

Anyway, passing over to autoconf ... --best, karl.

bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early

[Glenn Morris]

Done.

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bruno Haible]

Follow-up Comment #12, sr #110403 (project autoconf):

The bug exists also in the /bin/sh of Solaris OpenIndiana 20171031.

The symptom is this failure during configure:

configure: creating ./config.status
config.status: creating Makefile
gawk: ./conf0h1pqt/subs.awk:1691: cat >>"$ac_tmp/subs1.awk" <<_ACAWK &&
gawk: ./conf0h1pqt/subs.awk:1691: ^ syntax error
config.status: error: could not create Makefile


Find attached a tarball that contains
- the configure script,
- the broken config.status,
- the correct config.status (generated with CONFIG_SHELL=/usr/bin/bash).

(file #51026)
___

Additional Item Attachment:

File name: sh-bug.tar.gz  Size:363 KB
<https://file.savannah.gnu.org/file/sh-bug.tar.gz?file_id=51026>



___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

Follow-up Comment #11, sr #110403 (project autoconf):

I see that https://www.illumos.org/issues/13405 addresses updating Illumos
ksh93 to a recent version.  The description says that the task is 'hard' but
the task is showing progress made.

Regardless, a note about the bug is certainly useful since a fix would not be
deployed and available to all for some time.

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Zack Weinberg]

Update of sr #110403 (project autoconf):

  Status:   Need Info => Not Autoconf   
 Open/Closed:Open => Closed 

___

Follow-up Comment #10:

I have filed https://www.illumos.org/issues/13434 for the shell bug.  Do you
think it's worth mentioning this issue in the Autoconf release notes?

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bruno Haible]

Bob Friesenhahn wrote:
> > I would recommend to just document the problem and workaround in two places:
> > 1) in the OmniOS community,
> > 2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for
> > GNU people.
> 
> That seems reasonable.

OK, what can I write in (2)? Are the following values right?

solaris11omnios-x86-32-gcc  CC="gcc -m32 -O2"  CXX="g++ -m32 -O2" 
CONFIG_SHELL=/bin/bash

solaris11omnios-x86-64-gcc  CC="gcc -m64 -O2"  CXX="g++ -m64 -O2" 
CONFIG_SHELL=/bin/bash

Or, if you want, I can let you edit this table.

> This Google reference (which is likely based on Google Search data) is 
> very annoying to me and it seems irrelevant.  There is no need to 
> diminish a viable free operating system.

I didn't purposely diminish OmniOS. But Zack asked for our thoughts on
how to deal with a bug. As usual, "add workaround to the code" and
"add workaround to the documentation" are viable alternatives. In my
opinion, the size of the user base does play a role. If every other
circumstances were equal, I would spend more time on a workaround for
FreeBSD than on a workaround for OmniOS. And I would recommend the same
thing to Zack.

How to estimate the size of the user base of an OS? Like you, I dislike
Google. But their trends site is a way to do such estimations, and I know
of no other or better way. (For packages, but not for OSes, there is also
the Debian popularity contest.)

> In a similar spirit, I should point out that Illumos is doing better 
> than CLISP according to trends.google.com since the limited 
> popularlity is stable and not dwindling. ;-)

Indeed, CLISP failed to achieve world domination. JavaScript did, instead.
I failed. ;-)

Bruno

Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

On Thu, 24 Dec 2020, Bruno Haible wrote:


I would recommend to just document the problem and workaround in two places:
1) in the OmniOS community,
2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for
GNU people.


That seems reasonable.


It's not worth the complexity in Autoconf for a short-lived bug in a
small-community system, when a workaround is so easy to put in place.

References:
[1] https://en.wikipedia.org/wiki/Comparison_of_OpenSolaris_distributions
[2] trends.google.com


This Google reference (which is likely based on Google Search data) is 
very annoying to me and it seems irrelevant.  There is no need to 
diminish a viable free operating system.


In a similar spirit, I should point out that Illumos is doing better 
than CLISP according to trends.google.com since the limited 
popularlity is stable and not dwindling. ;-)


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bob Friesenhahn]

Follow-up Comment #9, sr #110403 (project autoconf):

Since the shell delivered with OmniOSce is provided by Illumos, the
appropriate bug tracker would be at
https://www.illumos.org/projects/illumos-gate/issues

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Bruno Haible]

Follow-up Comment #8, sr #110403 (project autoconf):

Given that
* OmniOS has an active development [1],
* The OpenSolaris community is approximately equally divided among OmniOS,
SmartOS, and OpenIndiana [2],
* You haven't found this bug in other Solaris derivatives,
* The workaround is to set the environment variable
CONFIG_SHELL=/path/to/bash,

I would recommend to just document the problem and workaround in two places:
1) in the OmniOS community,
2) at https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration for
GNU people.

It's not worth the complexity in Autoconf for a short-lived bug in a
small-community system, when a workaround is so easy to put in place.

References:
[1] https://en.wikipedia.org/wiki/Comparison_of_OpenSolaris_distributions
[2] trends.google.com


___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

[Zack Weinberg]

Update of sr #110403 (project autoconf):

 Summary: autoconf-2.70 AC_TYPE_INTMAX_T test failure under
OmniOS => autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh


___

Reply to this item at:

  <https://savannah.gnu.org/support/?110403>

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Nick Bowler]

On 2020-10-22, Zack Weinberg  wrote:
> I acknowledge that requiring double-quotation of AC_INIT arguments
> when they contain characters significant to M4 _should_ work; however,
> it did not work in my tests (which were not exactly the same as the
> above; see the "AC_INIT with unusual version strings" test case in
> tests/base.m4, on the branch).  Also, it increases the compat hit
> we're taking, since e.g.
>
> AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
> https://gmplib.org/manual/Reporting-Bugs.html], gmp)
>
> which also worked with 2.69, will now be considered invalid,

If this works in 2.69 I don't see why this snippet would be rendered
invalid if AC_INIT did not over/underquote, because ...

> Would you care to propose a complete patch to be applied on top of
> zack/ac-init-quoting?  In addition to "reverting hunks" you would need
> to make sure that AC_PACKAGE_* are always treated consistently within
> lib/autoconf/*.m4, fix the testsuite by adding double quotation to AC_INIT
> arguments where necessary, and document in both doc/autoconf.texi and NEWS
> the changed requirements for AC_INIT arguments.

... I am not suggesting we change any behaviour to AC_INIT arguments wrt.
quoting, as compared to Autoconf 2.69.  As far as I know this version
dutifully follows typical m4 quoting conventions, I am not aware of
any specific under/overquotation in existing releases.

This underquotation (2.69c) and overquotation (zack/ac-init-quoting
branch) is a behaviour change compared to 2.69.  I am proposing we NOT
change the amount of quoting, but rather we should stick with normal m4
conventions, which would avoid all the AC_INIT-related regressions I've
seen reported so far to this list.

Anyway, I should have some time on the weekend, I'll see what I can do
about proposing a proper patch :)

Cheers,
  Nick

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Nick Bowler]

On 22/10/2020, Zack Weinberg  wrote:
> On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler  wrote:
>> On 2020-10-22, Zack Weinberg  wrote:
>> > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert 
>> > wrote:
>> >>
>> >> On 10/21/20 6:15 AM, Zack Weinberg wrote:
>> >> > We*could*  add a special case in AC_INIT where, if any of the third,
>> >> > fourth, or fifth arguments contain the literal strings
>> >> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with
>> >> > the
>> >> > values of the first and second argument, respectively.  This would
>> >> > keep the GHC code working as-is.  I'm not sure whether that's a good
>> >> > idea; cc:ing Paul and Eric for their thoughts.
>> >>
>> >> I'm not following all the details here
>> >
>> > The concrete problem is that, without the hack I described, we cannot
>> > support both
>> >
>> > AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])
>> >
>> > and
>> >
>> > AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])
>>
>> I think this is missing the point.  The m4 way is that such an
>> email address should simply be double quoted to avoid the unwanted
>> m4 expansion, for example:
>>
>>   AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])
>
> I tried that and it doesn't work.  No amount of extra quotation (ok, I
> only went up to four levels before I gave up) will prevent the square
> brackets from being lost, if I don't have autoconf use m4_defn to set
> the value of the shell variable PACKAGE_BUGREPORT.

It works perfectly fine for me with Autoconf-2.69...

  % cat >configure.ac <<'EOF'
AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

AS_ECHO(["AC_PACKAGE_BUGREPORT"])
AS_ECHO(["$PACKAGE_BUGREPORT"])

AC_OUTPUT
EOF

  % autoconf-2.69
  % ./configure
  2.69
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

And it also works as expected with the zack/ac-init-quoting branch if I
simply revert the patch hunks identified earlier in this thread:

  % autoconf-zack-patched
  % ./configure
  2.69c.10-6487-dirty
  foo-bug@[192.0.2.1]
  foo-bug@[192.0.2.1]
  configure: creating ./config.status

If the hunks are not reverted, quotation problems are readily apparent:

  % autoconf-zack-unpatched
  2.69c.10-6487
  foo-bug@[192.0.2.1]
  [foo-bug@[192.0.2.1]]
  configure: creating ./config.status

(those patch hunks are not the only instances of overquotation added by the
patch, I see that the patch also overquotes the bugreport address in the
configure --help text)

Cheers,
  Nick

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Zack Weinberg]

On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler  wrote:
> On 2020-10-22, Zack Weinberg  wrote:
> > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert  wrote:
> >>
> >> On 10/21/20 6:15 AM, Zack Weinberg wrote:
> >> > We*could*  add a special case in AC_INIT where, if any of the third,
> >> > fourth, or fifth arguments contain the literal strings
> >> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
> >> > values of the first and second argument, respectively.  This would
> >> > keep the GHC code working as-is.  I'm not sure whether that's a good
> >> > idea; cc:ing Paul and Eric for their thoughts.
> >>
> >> I'm not following all the details here
> >
> > The concrete problem is that, without the hack I described, we cannot
> > support both
> >
> > AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])
> >
> > and
> >
> > AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])
>
> I think this is missing the point.  The m4 way is that such an
> email address should simply be double quoted to avoid the unwanted
> m4 expansion, for example:
>
>   AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

I tried that and it doesn't work.  No amount of extra quotation (ok, I
only went up to four levels before I gave up) will prevent the square
brackets from being lost, if I don't have autoconf use m4_defn to set
the value of the shell variable PACKAGE_BUGREPORT.

zw

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Nick Bowler]

On 2020-10-22, Zack Weinberg  wrote:
> On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert  wrote:
>>
>> On 10/21/20 6:15 AM, Zack Weinberg wrote:
>> > We*could*  add a special case in AC_INIT where, if any of the third,
>> > fourth, or fifth arguments contain the literal strings
>> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
>> > values of the first and second argument, respectively.  This would
>> > keep the GHC code working as-is.  I'm not sure whether that's a good
>> > idea; cc:ing Paul and Eric for their thoughts.
>>
>> I'm not following all the details here
>
> The concrete problem is that, without the hack I described, we cannot
> support both
>
> AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])
>
> and
>
> AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])

I think this is missing the point.  The m4 way is that such an
email address should simply be double quoted to avoid the unwanted
m4 expansion, for example:

  AC_INIT([bar], [1.0], [[foo-bug@[192.0.2.1]]])

This works already, as expected, in existing versions of Autoconf.

But if your package actually used such an email address today, it will
be broken by the patch due to the overquotation in AC_INIT.  To avoid
regressions like the one reported, and to be consistent with how most
macros are expected to function, we should simply not overquote in
the definition of AC_INIT.

Cheers,
  Nick

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Zack Weinberg]

On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert  wrote:
>
> On 10/21/20 6:15 AM, Zack Weinberg wrote:
> > We*could*  add a special case in AC_INIT where, if any of the third,
> > fourth, or fifth arguments contain the literal strings
> > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
> > values of the first and second argument, respectively.  This would
> > keep the GHC code working as-is.  I'm not sure whether that's a good
> > idea; cc:ing Paul and Eric for their thoughts.
>
> I'm not following all the details here

The concrete problem is that, without the hack I described, we cannot
support both

AC_INIT([foo], [1.0], [foo-...@foo.org], [foo-AC_PACKAGE_VERSION])

and

AC_INIT([bar], [1.0], [foo-bug@[192.0.2.1]])

I currently think supporting the latter is more important, based on
the not-at-all-scientific observation that one package was broken by
avoiding further expansion cycles when AC_PACKAGE_TARNAME is used, but
at least three packages were broken by extra expansion cycles
(compared to 2.69) eating punctuation in URLs.  I'm also, on net, not
a fan of the hack.

zw

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Paul Eggert]

On 10/21/20 6:15 AM, Zack Weinberg wrote:

We*could*  add a special case in AC_INIT where, if any of the third,
fourth, or fifth arguments contain the literal strings
`AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
values of the first and second argument, respectively.  This would
keep the GHC code working as-is.  I'm not sure whether that's a good
idea; cc:ing Paul and Eric for their thoughts.


I'm not following all the details here, but my kneejerk reaction is that we 
should avoid hacks like that. If AC_INIT is that poorly designed, the best 
approach might be to come up with a new macro that is better, and suggest that 
people use that instead AC_INIT; if so, perhaps the hack you suggest is the best 
we can do for the now-obsolescent AC_INIT.

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Sergei Trofimovich]

On Wed, 21 Oct 2020 09:15:41 -0400
Zack Weinberg  wrote:

> On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler  wrote:
> > On 2020-10-20, Sergei Trofimovich  wrote:  
> > > Initial bug is reported as autoconf failure on ghc-8.8.4:
> > > https://bugs.gentoo.org/750191
> > > There autconf 2.69 works, 2.69c does not.  
> ...
> > >   $ cat configure.ac
> > >   AC_INIT([The Glorious Glasgow Haskell Compilation System], [9.1.0],
> > > [glasgow-haskell-b...@haskell.org], [ghc-AC_PACKAGE_VERSION])
> > >
> > >   echo "$PACKAGE_VERSION"
> > >
> > >   AC_OUTPUT  
> 
> If I understand correctly, the intention is to have $PACKAGE_VERSION
> set to "9.1.0" and $PACKAGE_TARNAME set to "ghc-9.1.0"?

I think the intention is to have PACKAGE_VERSION=9.1.0 (and tarball)
for a release (RELEASE=YES in configure.ac).

For development versions PACKAGE_VERSION (and tarball
name) is mangled later in configure.ac after AC_INIT based on current
commit: https://github.com/ghc/ghc/blob/master/aclocal.m4#L1646

-- 

  Sergei

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Nick Bowler]

On 2020-10-21, Zack Weinberg  wrote:
> On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler  wrote:
>> Note: the change you report is introduced by Zack's fix for related
>> AC_INIT quoting regressions.  This patch is not included in 2.69c (or
>> even on git master), but does seem to be applied by the Gentoo package.
>
> Yeah, this is a "can't have it both ways" kind of thing.  We can
> reliably round-trip "unusual" characters (like the ones that appear
> all the time in URLs and email addresses) through AC_INIT's arguments,
> or we can expand macros in those arguments even when they're quoted on
> input; I don't think there's any way to do both.

M4 macros (including AC_INIT) should normally follow the m4 quoting rule
of thumb, which is that the amount of quotation should exactly equal the
depth of macro expansion.  Remembering that extra quotation added by
macros such as m4_defn and m4_dquote count for this.

Previously AC_INIT had not enough quotation, i.e., less levels of
quotation than expansion, which lead to unexpected behaviour.

Now, with the patch, AC_INIT is adding more levels of quotation than
expansion, leading to different unexpected behaviour.

M4 macros are happiest when the level of quotation is just right :)

> This only works by accident in 2.69, incidentally.  AC_PACKAGE_VERSION
> is defined *after* AC_PACKAGE_TARNAME (see _AC_INIT_PACKAGE, lines
> 235-261 of $prefix/share/autoconf/general.m4) so both old and new
> autoconf set AC_PACKAGE_TARNAME to the literal string
> "ghc-AC_PACKAGE_VERSION".

While I agree it's probably a bit "naughty" to use AC_PACKAGE_VERSION
in the argument to AC_INIT it is a red herring.  Use of any macro would
have the exact same problem.

I'd expect double-quoted arguments to AC_INIT to be similarly broken
with this patch while previously they would work as expected.

> The value undergoes an extra round of expansion when it's used to set
> the shell variable PACKAGE_TARNAME (lines 416-428 of the same file).
> This extra round of expansion is undesirable in general.

I don't think I agree, when macro expansion is undesired the normal way
is to double-quote the arguments, which properly suppresses expansion
when macro definitions follow quoting the rule of thumb.

Cheers,
  Nick

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Zack Weinberg]

On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler  wrote:
> On 2020-10-20, Sergei Trofimovich  wrote:
> > Initial bug is reported as autoconf failure on ghc-8.8.4:
> > https://bugs.gentoo.org/750191
> > There autconf 2.69 works, 2.69c does not.
...
> >   $ cat configure.ac
> >   AC_INIT([The Glorious Glasgow Haskell Compilation System], [9.1.0],
> > [glasgow-haskell-b...@haskell.org], [ghc-AC_PACKAGE_VERSION])
> >
> >   echo "$PACKAGE_VERSION"
> >
> >   AC_OUTPUT

If I understand correctly, the intention is to have $PACKAGE_VERSION
set to "9.1.0" and $PACKAGE_TARNAME set to "ghc-9.1.0"?

> Note: the change you report is introduced by Zack's fix for related
> AC_INIT quoting regressions.  This patch is not included in 2.69c (or
> even on git master), but does seem to be applied by the Gentoo package.

Yeah, this is a "can't have it both ways" kind of thing.  We can
reliably round-trip "unusual" characters (like the ones that appear
all the time in URLs and email addresses) through AC_INIT's arguments,
or we can expand macros in those arguments even when they're quoted on
input; I don't think there's any way to do both.

This only works by accident in 2.69, incidentally.  AC_PACKAGE_VERSION
is defined *after* AC_PACKAGE_TARNAME (see _AC_INIT_PACKAGE, lines
235-261 of $prefix/share/autoconf/general.m4) so both old and new
autoconf set AC_PACKAGE_TARNAME to the literal string
"ghc-AC_PACKAGE_VERSION".  The value undergoes an extra round of
expansion when it's used to set the shell variable PACKAGE_TARNAME
(lines 416-428 of the same file).  This extra round of expansion is
undesirable in general.

You can fix this in configure.ac without repeating the version number
by defining an extra M4 macro and using it in both arguments:

m4_define([ghc_VERSION], [9.1.0])
AC_INIT([The Glorious Glasgow Haskell Compilation System],
   m4_defn([ghc_VERSION]),
   [glasgow-haskell-b...@haskell.org],
   [ghc-]m4_defn([ghc_VERSION]))

I'm being extra careful with quotation here; `ghc_VERSION` and
`m4_defn([ghc_VERSION])` both expand to the definition of ghc_VERSION,
but the latter quotes its output. This would matter if the value of
ghc_VERSION could contain more M4 macros, which it *currently*
doesn't...

(If you don't mind, I think I might add this to the manual as an
example of computing the arguments to AC_INIT, with all the
GHC-specific terms removed, of course.)

We *could* add a special case in AC_INIT where, if any of the third,
fourth, or fifth arguments contain the literal strings
`AC_PACKAGE_NAME` or `AC_PACKAGE_VERSION`, those are replaced with the
values of the first and second argument, respectively.  This would
keep the GHC code working as-is.  I'm not sure whether that's a good
idea; cc:ing Paul and Eric for their thoughts.

zw

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Sergei Trofimovich]

On Tue, 20 Oct 2020 16:57:16 -0400
Nick Bowler  wrote:

> Hi,
> 
> On 2020-10-20, Sergei Trofimovich  wrote:
> > Initial bug is reported as autoconf failure on ghc-8.8.4:
> > https://bugs.gentoo.org/750191
> > There autconf 2.69 works, 2.69c does not.  
> 
> Note: the change you report is introduced by Zack's fix for related
> AC_INIT quoting regressions.  This patch is not included in 2.69c (or
> even on git master), but does seem to be applied by the Gentoo package.
> 
> The 2.69c release version seems to handle the example fine.

Oh, I did not realize we carry an out of tree patch with such a behaviour
change. Redirected the bug to Gentoo autoconf package maintainers.

Thank you!

-- 

  Sergei

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Nick Bowler]

Hi,

On 2020-10-20, Sergei Trofimovich  wrote:
> Initial bug is reported as autoconf failure on ghc-8.8.4:
> https://bugs.gentoo.org/750191
> There autconf 2.69 works, 2.69c does not.

Note: the change you report is introduced by Zack's fix for related
AC_INIT quoting regressions.  This patch is not included in 2.69c (or
even on git master), but does seem to be applied by the Gentoo package.

The 2.69c release version seems to handle the example fine.

> Here is the minimal example:
>
> OK:
>
>   $ cat configure.ac
>   AC_INIT([The Glorious Glasgow Haskell Compilation System], [9.1.0],
> [glasgow-haskell-b...@haskell.org], [ghc-AC_PACKAGE_VERSION])
>
>   echo "$PACKAGE_VERSION"
>
>   AC_OUTPUT
>   $ autoconf-2.69
>   $ ./configure
>   9.1.0
>   configure: creating ./config.status
>
> BAD:
>
>   $ autoconf-2.70_beta2
>   configure.ac:1: error: possibly undefined macro: AC_PACKAGE_VERSION
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.

Yes I think now Zack's underquotation fixes have added the opposite
problem.  There is now too much quotation so the tarname (and other
arguments) are not fully expanded when used.

At least these changes should probably be simply dropped from the patch
or at least they perhaps need more consideration...

@@ -436,18 +427,12 @@ AC_SUBST([SHELL])dnl
 AC_SUBST([PATH_SEPARATOR])dnl

 # Identity of this package.
-AC_SUBST([PACKAGE_NAME],
-[m4_ifdef([AC_PACKAGE_NAME],  ['AC_PACKAGE_NAME'])])dnl
-AC_SUBST([PACKAGE_TARNAME],
-[m4_ifdef([AC_PACKAGE_TARNAME],   ['AC_PACKAGE_TARNAME'])])dnl
-AC_SUBST([PACKAGE_VERSION],
-[m4_ifdef([AC_PACKAGE_VERSION],   ['AC_PACKAGE_VERSION'])])dnl
-AC_SUBST([PACKAGE_STRING],
-[m4_ifdef([AC_PACKAGE_STRING],['AC_PACKAGE_STRING'])])dnl
-AC_SUBST([PACKAGE_BUGREPORT],
-[m4_ifdef([AC_PACKAGE_BUGREPORT], ['AC_PACKAGE_BUGREPORT'])])dnl
-AC_SUBST([PACKAGE_URL],
-[m4_ifdef([AC_PACKAGE_URL],   ['AC_PACKAGE_URL'])])dnl
+AC_SUBST([PACKAGE_NAME],  ['m4_defn([AC_PACKAGE_NAME])'])dnl
+AC_SUBST([PACKAGE_TARNAME],   ['m4_defn([AC_PACKAGE_TARNAME])'])dnl
+AC_SUBST([PACKAGE_VERSION],   ['m4_defn([AC_PACKAGE_VERSION])'])dnl
+AC_SUBST([PACKAGE_STRING],['m4_defn([AC_PACKAGE_STRING])'])dnl
+AC_SUBST([PACKAGE_BUGREPORT], ['m4_defn([AC_PACKAGE_BUGREPORT])'])dnl
+AC_SUBST([PACKAGE_URL],   ['m4_defn([AC_PACKAGE_URL])'])dnl

 m4_divert_pop([DEFAULTS])dnl
 m4_wrap_lifo([m4_divert_text([DEFAULTS],
@@ -1099,9 +1084,8 @@ Fine tuning of the installation directories:
   --infodir=DIR   info documentation [DATAROOTDIR/info]
   --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
   --mandir=DIRman documentation [DATAROOTDIR/man]
-]AS_HELP_STRING([--docdir=DIR],
-  [documentation root ]@<:@DATAROOTDIR/doc/m4_ifset([AC_PACKAGE_TARNAME],
-[AC_PACKAGE_TARNAME], [PACKAGE])@:>@)[
+  --docdir=DIRdocumentation root @<:@DATAROOTDIR/doc/]dnl
+m4_default_quoted(m4_defn([AC_PACKAGE_TARNAME]), [PACKAGE])[@:>@
   --htmldir=DIR   html documentation [DOCDIR]
   --dvidir=DIRdvi documentation [DOCDIR]
   --pdfdir=DIRpdf documentation [DOCDIR]

If you drop those two hunks from Zack's patch the example should work again.

Cheers,
  Nick

AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

[Sergei Trofimovich]

Initial bug is reported as autoconf failure on ghc-8.8.4:
https://bugs.gentoo.org/750191
There autconf 2.69 works, 2.69c does not.

Here is the minimal example:

OK:

  $ cat configure.ac
  AC_INIT([The Glorious Glasgow Haskell Compilation System], [9.1.0], 
[glasgow-haskell-b...@haskell.org], [ghc-AC_PACKAGE_VERSION])

  echo "$PACKAGE_VERSION"

  AC_OUTPUT
  $ autoconf-2.69
  $ ./configure
  9.1.0
  configure: creating ./config.status

BAD:

  $ autoconf-2.70_beta2
  configure.ac:1: error: possibly undefined macro: AC_PACKAGE_VERSION
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Initializing-configure.html
says AC_INIT should define the AC_PACKAGE_VERSION, but evaluation probably 
happens later.

Should autoconf restore the old behaviour or should ghc adapt?
If we are to adapt what would be the best way not to repeat the version?

Thank you!

-- 

  Sergei

Re: autoconf bug tracking?

[Glenn Morris]

Zack Weinberg wrote:

> Would it be possible for you to make bugs reported against autoconf in
> debbugs send mail to bug-autoconf@gnu.org and not generate warnings,
> but not have autoconf show up in the list of packages officially using
> debbugs? 

To do that, just add an entry to /etc/debbugs/Maintainers on d.g.o.
(Seems an odd halfway house to me. Note that only ~ 1 debbugs report was
assigned to autoconf in over a decade of operation.)

Re: autoconf bug tracking?

[Zack Weinberg]

On Thu, Sep 3, 2020 at 8:26 PM Bob Proulx  wrote:
>
> We have this list of projects that have been configured for the GNU
> BTS instance running on debbugs.
>
> https://debbugs.gnu.org/Packages.html
>
> As you can tell there are quite a few.  But it's not all projects.
> It's projects that have asked for it.  No one is pushing the BTS upon
> projects.  But certainly if anyone wants to use it then it is
> available for their use.  And also the Savannah tracker is also
> available for use.
>
> There is no effort to push anyone to any particular tool.  It is
> completely up to the maintainers to choose.  And there is no plan to
> phase out either of the trackers.

Thanks for the explanation.

I think there is a strong case for switching Autoconf to debbugs
simply because Automake and Libtool are already using debbugs.  These
projects are closely coupled and we are probably going to want to
reassign bugs from one to another of them in the future.

The other project that is closely coupled with Autoconf is Gnulib, and
it isn't using _either_ of the gnu.org bug trackers as far as I can tell.
I'm cc:ing Paul Eggert in case he wants to weigh in.

> > and anyway I think a release freeze is not the time to be changing
> > trackers.
>
> No disagreement or complaints.
...
> If autoconf is going to use the BTS in the future, which I only
> mention because you said you would rather be using it, then let's do
> nothing for the moment.  Then it can use it in the future.  Leave the
> bugs assigned to the unregistered autoconf project in the BTS.  And
> just handle them normally.  The submitter won't know the difference.
> The BTS is only generating warnings as a typo protection against
> assigning to a non-existent typo error.

Would it be possible for you to make bugs reported against autoconf in
debbugs send mail to bug-autoconf@gnu.org and not generate warnings,
but not have autoconf show up in the list of packages officially using
debbugs?  If that's too hard, don't worry about it, but it seems like
that might be a reasonable way to address the current situation where
help-debbugs is getting noise traffic, without committing Autoconf to
any plan just yet.

zw

Re: autoconf bug tracking?

[Bob Proulx]

Hi Zack,

Zack Weinberg wrote:
> Autoconf is currently using the Savannah built-in bug tracker:
> https://savannah.gnu.org/support/?group=autoconf
> 
> I'd personally rather be using debbugs, but I don't know why gnu.org
> has two bug trackers in the first place or whether one of them is
> scheduled to be phased out,

A question that I can answer!  :-)

Glenn Morris working on Emacs (and I am sure others) wanted to use the
Debian BTS for Emacs rather than the Savannah tracker.  Therefore
Glenn talked the FSF admins into setting up a VM debbugs.gnu.org for
the purpose of hosting a GNU instance of the Debian BTS.  Then
converted Emacs over to using the BTS.

And once that was set up other people wanted to use the BTS for their
projects too.  I remember Jim Meyering jumped at the chance to use it
for Coreutils as an early adopter.  And others followed.  Quite a few
projects use it now.

We have this list of projects that have been configured for the GNU
BTS instance running on debbugs.

https://debbugs.gnu.org/Packages.html

As you can tell there are quite a few.  But it's not all projects.
It's projects that have asked for it.  No one is pushing the BTS upon
projects.  But certainly if anyone wants to use it then it is
available for their use.  And also the Savannah tracker is also
available for use.

There is no effort to push anyone to any particular tool.  It is
completely up to the maintainers to choose.  And there is no plan to
phase out either of the trackers.

> and anyway I think a release freeze is not the time to be changing
> trackers.

No disagreement or complaints.  The question was simply about the best
thing to do since we had this bug come into the automake tracker and
reassigned to the autoconf tracker, and fell into the pitfall that is
autoconf does not use the BTS on debbugs, generated warnings which
Karl noticed due to this, and got me involved since I am involved in
both of them.

If autoconf is going to use the BTS in the future, which I only
mention because you said you would rather be using it, then let's do
nothing for the moment.  Then it can use it in the future.  Leave the
bugs assigned to the unregistered autoconf project in the BTS.  And
just handle them normally.  The submitter won't know the difference.
The BTS is only generating warnings as a typo protection against
assigning to a non-existent typo error.  The only important thing is
that maintainers need to know to look there since it is at this moment
not an expected place for bugs to show up.

If autoconf is not going to use the BTS in the future then we should
empty the BTS autoconf tickets.  Open a new ticket in the Savannah
tracker for each of them, paste in all of the appropriate data, and
close the one in the debbugs BTS.  That way we don't have dangling
tickets that no one will ever see.  And if we don't close out the
autoconf bugs in the BTS then people will see open bugs there and add
more bugs there!  We should empty it so that it doesn't look available
for use there.

Or any other process flow that makes sense to you.

> I did see the bug you want to reassign to  autoconf and I intend to
> look at it this weekend.

Bob

Re: autoconf bug tracking?

[Zack Weinberg]

On Thu, Sep 3, 2020 at 5:59 PM Karl Berry  wrote:
>
> Hi Zack and all - um, I guess autoconf is not using the email bug
> tracker?  Do you intend it to? If not, I imagine Bob (cc'd) can disable
> it completely somehow. (Thanks for the info, Bob.)

Autoconf is currently using the Savannah built-in bug tracker:
https://savannah.gnu.org/support/?group=autoconf

I'd personally rather be using debbugs, but I don't know why gnu.org
has two bug trackers in the first place or whether one of them is
scheduled to be phased out, and anyway I think a release freeze is not
the time to be changing trackers.

I did see the bug you want to reassign to  autoconf and I intend to
look at it this weekend.

zw

Re: autoconf bug tracking?

[Eric Blake]

On 9/3/20 4:59 PM, Karl Berry wrote:

Hi Zack and all - um, I guess autoconf is not using the email bug
tracker?  Do you intend it to? If not, I imagine Bob (cc'd) can disable
it completely somehow. (Thanks for the info, Bob.)

There is currently one other bug besides the one I just "reassign"ed:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=autoconf


We haven't been using it, but I would not be opposed to flipping the 
switch to start using it.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

autoconf bug tracking?

[Karl Berry]

Hi Zack and all - um, I guess autoconf is not using the email bug
tracker?  Do you intend it to? If not, I imagine Bob (cc'd) can disable
it completely somehow. (Thanks for the info, Bob.)

There is currently one other bug besides the one I just "reassign"ed:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=autoconf

Thanks,
Karl

[PATCH] bug fix - AS_IF with blank false branch

[Jannick]

Please find attached suggested patches for your consideration and review.

Bug fix for

AS_IF([false],[echo OK],[[]])

yielding the syntactically incorrect shell code:

if false; then :
  echo OK
else

fi


I hope that sending patches to the list as attachments is OK and they will
come through to the list.

Thanks,
J.
>From f38a8134c63a6bf5fbd1d7a33f85387e0864b188 Mon Sep 17 00:00:00 2001
From: Jannick 
Date: Thu, 26 Dec 2019 03:06:29 +0100
Subject: [PATCH 2/2] m4sh/AS_IF: bug fix of previous buggy test case

* lib/m4sugar/m4sh.m4: replace `else' by `else :' in `_AS_IF_ELSE'.
---
 lib/m4sugar/m4sh.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index d7e41673..4d357107 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -637,7 +637,7 @@ then :
 ])
 m4_define([_AS_IF_ELSE],
 [m4_ifnblank([$1],
-[else
+[else :
   $1
 ])])
 
-- 
2.24.1.windows.2

>From 4e55d3bfe31c4f869b2fb110140b379fe803c5ec Mon Sep 17 00:00:00 2001
From: Jannick 
Date: Thu, 26 Dec 2019 02:53:01 +0100
Subject: [PATCH 1/2] m4sh/AS_IF: add a buggy test for AS_IF with blank false
 branch

The test

make check TESTSUITEFLAGS='-e -k m4sh,m4_map_args_pair'

fails, since m4sh generates from

AS_IF([false], [echo OK], [[]])

the syntactically incorrect shell code

if false; then :
  echo OK
else

fi

* tests/m4sh.at: add test `AS_IF([false], [:], [[]])'
---
 tests/m4sh.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/m4sh.at b/tests/m4sh.at
index cbdfcb62..e7d3c1ee 100644
--- a/tests/m4sh.at
+++ b/tests/m4sh.at
@@ -1240,7 +1240,7 @@ AS_CASE([`touch file; false`]) && test -f file && echo 
fifteen
 dnl The next line is badly underquoted; don't intentionally copy this style.
 AS_CASE([foo], [foo], m4_do(AS_CASE([bar], [bar], [echo sixteen])))
 dnl Handle blank arguments.
-AS_IF([false], [:], [ ]) && AS_CASE([foo], [foo], []
+AS_IF([false], [:], [ ]) && AS_IF([false], [:], [[]]) && AS_CASE([foo], [foo], 
[]
 ) && echo seventeen
 m4_define([empty])AS_IF([:], [empty]
 ) && AS_CASE([foo], [foo], [empty]) && echo eighteen
-- 
2.24.1.windows.2

Autoconf bug: space in volume name

[John Dundas, III]

Autoconf maintainers,

I may have encountered a bug in the autoconf suite.  In testing one of 
my own very simple projects, things work as expected until I use a 
volume that has a blank or space embedded in the volume name.  The 
following is an example running from a volume with an embedded space:


ddhcp-137-164-83-65:sparse johndundas$ pwd
/Volumes/NO NAME/sparse
ddhcp-137-164-83-65:sparse johndundas$ autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/local/bin/autoconf
autoreconf: configure.ac: not using Autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'
ddhcp-137-164-83-65:sparse johndundas$ ./configure
./configure: line 1: syntax error near unexpected token `('
./configure: line 1: `m4trace:aclocal.m4:679: -1- AC_SUBST([am__quote])'
ddhcp-137-164-83-65:sparse johndundas$

Whereas running the same code from a volume without a space in the name 
yields:


ddhcp-137-164-83-65:sparse johndundas$ pwd
/Users/johndundas/Documents/Projects/sparse
ddhcp-137-164-83-65:sparse johndundas$ autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/local/bin/autoconf
autoreconf: running: /usr/local/bin/autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'
ddhcp-137-164-83-65:sparse johndundas$ ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for a BSD-compatible install... /usr/local/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for off_t... yes
checking for ftruncate... yes
checking for memset... yes
checking for strerror... yes
checking for strrchr... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
configure: Configured to build sputils

sputils Version 1.0

  Host setup:
  Install prefix:   /usr/local
  Compiler: gcc
   CFLAGS:  -g -O2
   CPPFLAGS:
   LDFLAGS:
   LIBS:

Now type 'make []'
  where the optional  is:
    all    - build all binaries
    check  - validate correct operation
    install    - install everything

ddhcp-137-164-83-65:sparse johndundas$

This under Mac OS X 10.14.6, though I think other systems would be 
similarly affected.


ddhcp-137-164-83-65:sparse johndundas$ uname -a
Darwin ddhcp-137-164-83-65.cenic.org 18.7.0 Darwin Kernel Version 
18.7.0: Tue Aug 20 16:57:14 PDT 2019; 
root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64 i386 MacBookPro14,3 Darwin

ddhcp-137-164-83-65:sparse johndundas$

If you need additional information, please let me know.

Thanks,

John

Re: Possible bug in 'ln -s target dir' check code --

[Perry Hutchison]

"Townsend, Paul"  wrote:

> I am probably incorrectly interpreting the autoconf code that
> checks whether or not 'ln -s target dir' works.  It seems the
> check code is satisfied if
>
>   mkdir a
>
>   touch b
>
>   ln -s b a
>
> works without aborting.  On Ubuntu this does create a 'b' symlink
> in 'a' but that symlink is an infinite a/b->a/b.

AFAIK this has been the normal behavior of "ln -s" for as long
as symlinks have existed.  Indeed, because "ln -s" (unlike "ln"
without -s) does not stat the link target, it would still work
even if you left out the "touch b".

> In fact I think the only way to succeed is to use
>
>   ln -s $PWD/b a

or, better, "ln -s ../b a"

One way to help keep such things straight is to make symlinks only
in the current directory, e.g.

  ( cd a && ln -s ../b . )

> i.e., the ln app should be a heck of a lot smarter.

Arguably it should have originally been designed to issue a warning
if the target does not exist or if the result will be a loop, but to
change its behavior now would break backward compatibility.

Possible bug in 'ln -s target dir' check code --

[Townsend, Paul]

I am probably incorrectly interpreting the autoconf code that checks whether or 
not 'ln -s target dir' works.  It seems the check code is satisfied if


  mkdir a

  touch b

  ln -s b a


works without aborting.  On Ubuntu this does create a 'b' symlink in 'a' but 
that symlink is an infinite a/b->a/b.  In fact I think the only way to succeed 
is to use


  ln -s $PWD/b a


i.e., the ln app should be a heck of a lot smarter.


--  Thanks,

--Paul Townsend

bug in perl autoscan

[Joshua Branson]

I just installed autoscan version 2.21 (on guixSD), and it gave me this
warning in a recently un-tar-ed linphone.tar.gz directory.

#BEGIN_SRC sh
  autoscan
#END_SRC

Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.30), passed through in regex; marked by <-- HERE in m/\${ <-- HERE [^\}]*}/ 
at /home/joshua/.guix-profile/bin/autoscan line 361.
configure.ac: warning: missing AC_CHECK_FUNCS([__argz_count]) wanted by: 
intl/l10nflist.c:323
configure.ac: warning: missing AC_CHECK_FUNCS([__argz_next]) wanted by: 
intl/l10nflist.c:371
configure.ac: warning: missing AC_CHECK_FUNCS([__argz_stringify]) wanted 
by: intl/l10nflist.c:248
configure.ac: warning: missing AC_CHECK_FUNCS([atexit]) wanted by: 
gtk/chat.c:54
configure.ac: warning: missing AC_CHECK_FUNCS([dup2]) wanted by: 
console/shell.c:195
configure.ac: warning: missing AC_CHECK_FUNCS([inet_ntoa]) wanted by: 
coreapi/misc.c:415
configure.ac: warning: missing AC_CHECK_FUNCS([localtime_r]) wanted by: 
gtk/main.c:852
configure.ac: warning: missing AC_CHECK_FUNCS([memmove]) wanted by: 
coreapi/linphonecall.c:4770
configure.ac: warning: missing AC_CHECK_FUNCS([mempcpy]) wanted by: 
intl/localealias.c:213
configure.ac: warning: missing AC_CHECK_FUNCS([memset]) wanted by: 
gtk/status_notifier.c:458
configure.ac: warning: missing AC_CHECK_FUNCS([mkdir]) wanted by: 
gtk/logging.c:103
configure.ac: warning: missing AC_CHECK_FUNCS([munmap]) wanted by: 
intl/loadmsgcat.c:1005
configure.ac: warning: missing AC_CHECK_FUNCS([nl_langinfo]) wanted by: 
coreapi/sqlite3_bctbx_vfs.c:272
configure.ac: warning: missing AC_CHECK_FUNCS([pow]) wanted by: 
coreapi/linphonecall.c:2859
configure.ac: warning: missing AC_CHECK_FUNCS([putenv]) wanted by: 
intl/cat-compat.c:199
configure.ac: warning: missing AC_CHECK_FUNCS([realpath]) wanted by: 
coreapi/lpconfig.c:103
configure.ac: warning: missing AC_CHECK_FUNCS([regcomp]) wanted by: 
coreapi/account_creator.c:262
configure.ac: warning: missing AC_CHECK_FUNCS([setenv]) wanted by: 
intl/cat-compat.c:196
configure.ac: warning: missing AC_CHECK_FUNCS([setlocale]) wanted by: 
gtk/main.c:2187
configure.ac: warning: missing AC_CHECK_FUNCS([socket]) wanted by: 
coreapi/misc.c:296
configure.ac: warning: missing AC_CHECK_FUNCS([strcasecmp]) wanted by: 
gtk/friendlist.c:645
configure.ac: warning: missing AC_CHECK_FUNCS([strchr]) wanted by: 
gtk/support.c:218
configure.ac: warning: missing AC_CHECK_FUNCS([strcspn]) wanted by: 
intl/loadmsgcat.c:800
configure.ac: warning: missing AC_CHECK_FUNCS([strdup]) wanted by: 
gtk/main.c:196
configure.ac: warning: missing AC_CHECK_FUNCS([strerror]) wanted by: 
gtk/singleinstance.c:82
configure.ac: warning: missing AC_CHECK_FUNCS([strncasecmp]) wanted by: 
tools/generator.cc:213
configure.ac: warning: missing AC_CHECK_FUNCS([strpbrk]) wanted by: 
coreapi/linphonecore.c:993
configure.ac: warning: missing AC_CHECK_FUNCS([strrchr]) wanted by: 
gtk/main.c:198
configure.ac: warning: missing AC_CHECK_FUNCS([strstr]) wanted by: 
gtk/support.c:144
configure.ac: warning: missing AC_CHECK_FUNCS([strtol]) wanted by: 
console/linphonec.c:1292
configure.ac: warning: missing AC_CHECK_FUNCS([strtoull]) wanted by: 
coreapi/proxy.c:174
configure.ac: warning: missing AC_CHECK_HEADERS([argz.h]) wanted by: 
intl/l10nflist.c:33
configure.ac: warning: missing AC_CHECK_HEADERS([fcntl.h]) wanted by: 
console/wav2raw.c:8
configure.ac: warning: missing AC_CHECK_HEADERS([langinfo.h]) wanted by: 
intl/loadmsgcat.c:61
configure.ac: warning: missing AC_CHECK_HEADERS([libintl.h]) wanted by: 
gtk/linphone.h:58
configure.ac: warning: missing AC_CHECK_HEADERS([limits.h]) wanted by: 
build/wp8/zlib/zconf.h:397
configure.ac: warning: missing AC_CHECK_HEADERS([locale.h]) wanted by: 
gtk/main.c:55
configure.ac: warning: missing AC_CHECK_HEADERS([malloc.h]) wanted by: 
intl/cat-compat.c:30
configure.ac: warning: missing AC_CHECK_HEADERS([netdb.h]) wanted by: 
console/linphonec.c:51
configure.ac: warning: missing AC_CHECK_HEADERS([nl_types.h]) wanted by: 
intl/cat-compat.c:35
configure.ac: warning: missing AC_CHECK_HEADERS([stddef.h]) wanted by: 
build/wp8/zlib/zconf.h:435
configure.ac: warning: missing AC_CHECK_HEADERS([stdio_ext.h]) wanted by: 
intl/localealias.c:33
configure.ac: warning: missing AC_CHECK_HEADERS([sys/ioctl.h]) wanted by: 
daemon/daemon.cc:22
configure.ac: warning: missing AC_CHECK_HEADERS([sys/socket.h]) wanted by: 
console/linphonec.c:49
configure.ac: warning: missing AC_CHECK_HEADERS([sys/time.h]) wanted by: 
console/linphonec.c:50
configure.ac: warning: missing AC_CHECK_HEADERS([wchar.h]) wanted by: 
include/MSVC/stdint.h:52
configure.ac: warning: missing AC_CHECK_HEADER_STDBOOL wanted by: 
wrappers/cpp/object.cc:63
configure.ac: warning: missing AC_FUNC_ALLOCA wanted by: 
intl/localealias.c:42

Re: Potential bug in AC_CONFIG_SRCDIR

[Nick Bowler]

Hi Michael,
On 2019-01-07, Michael Cress  wrote:
> I am observing some strange behavior ( see comments in snippet ) with the
> AC_CONFIG_SRCDIR macro when using the configure.ac snippet below.
[...]
> #Define a subdirectory which contains the source files ( a separate Git repo
> )
> DCMSGSRCDIR=DockControllerImplv1_Messages_src
> AC_SUBST([DCMSGSRCDIR], [$DCMSGSRCDIR])
[...]
> #This also works
> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
> AC_CONFIG_SRCDIR([DockControllerImplv1_Messages_src/include/dockcontrollermsg.h])

The reason this works is because the second expansion of AC_CONFIG_SRCDIR
replaces the first one, hiding the problematic variable reference.

> # This ***does not*** work
>
> # This second use of the variable doesn't work and fails with ‘configure:
> error: cannot find sources (/include/dockcontrollermsg.h) in . or ..’.
>
> # Is this a bug?

I'd say no, although the documentation perhaps could be improved to
help the programmer understand the limitations.

> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
> AC_CONFIG_SRCDIR([$DCMSGSRCDIR/include/dockcontrollermsg.h])

This one fails because the last AC_CONFIG_SRCDIR expansion has the
problematic variable reference.

The "problem" is that AC_CONFIG_SRCDIR does its stuff very early in the
configure script: long before any normal shell assignments you put in
your script.  So DCMSGSRCDIR is not defined at the point it is used,
and so you get the wrong filename.

If you really want to reference shell variables in AC_CONFIG_SRCDIR you
need to be sure they are set in the DEFAULTS diversion.  But there seems
to be little point.  The only thing AC_CONFIG_SRCDIR really does is help
detect "operator error" if they botch the --srcdir option to configure,
so configure can print a better error message in this case.  Just point
it at any one file you want (ideally choose a file that is unlikely to
exist in other people's packages) and don't use any shell variables.

Cheers,
  Nick

Potential bug in AC_CONFIG_SRCDIR

[Michael Cress]

Greetings:

I am observing some strange behavior ( see comments in snippet ) with the 
AC_CONFIG_SRCDIR macro when using the configure.ac snippet below.



…

#Define a subdirectory which contains the source files ( a separate Git repo )
DCMSGSRCDIR=DockControllerImplv1_Messages_src
AC_SUBST([DCMSGSRCDIR], [$DCMSGSRCDIR])


#This works
# AC_CONFIG_SRCDIR([DockControllerImplv1_Messages_src/src/dockcontrollermsg.c])
# 
AC_CONFIG_SRCDIR([DockControllerImplv1_Messages_src/include/dockcontrollermsg.h])


#This also works
AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
AC_CONFIG_SRCDIR([DockControllerImplv1_Messages_src/include/dockcontrollermsg.h])


# This ***does not*** work

# This second use of the variable doesn't work and fails with ‘configure: 
error: cannot find sources (/include/dockcontrollermsg.h) in . or ..’.

# Is this a bug?
AC_CONFIG_SRCDIR([$DCMSGSRCDIR/src/dockcontrollermsg.c])
AC_CONFIG_SRCDIR([$DCMSGSRCDIR/include/dockcontrollermsg.h])

…




Thank you,

Michael Cress



-- 

Re: Fwd: BUG report using autoconf…

[Eric Blake]

On 02/05/2018 04:49 PM, aotto wrote:

You are correct that autoconf's detection of unexpanded macros is
unaware of comment syntax.  Would you like to prepare a patch to the
post-processing pass that looks for unexpanded macros to first filter
out all comment lines?


Checking for unexpected names inside comments is different from checking 
for intentional output embedded in error messages, where the code has to 
work even without comments protecting the text.




the problem is not only the comment… today I had a "string" with 
macroname inside in the file
acinclude.m4… and "aclocal --force -I m4" run "forever" and eat all my 
memory… example:


AC_DEFUN([SC_ENABLE_DEBUG], [
    AS_IF([test "x$config_site" = "xyes"], [
  AC_MSG_NOTICE(["ENABLE_DEBUG: using 'config.site' defaults"])
…

if you switch ENABLE_DEBUG to SC_ENABLE_DEBUG… then you have a really 
BIG problem… :-)


That's why the manual suggests that you use a quadrigraph for cases like 
that, as in:


AC_MSG_NOTICE(["SC_@@ENABLE_DEBUG: "])

where the @@ quadrigraph expands to the empty string AFTER all 
checking for unexpanded macros has taken place, and its presence in the 
meantime is enough to prevent unintended infinite recursion of trying to 
expand the SC_ENABLE_DEBUG macro from its own output.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Fwd: BUG report using autoconf…

[aotto]

 Weitergeleitete Nachricht 
Betreff:BUG report using autoconf…
Datum:  Sun, 4 Feb 2018 23:30:01 +0100
Von:aotto <aotto1...@t-online.de>
An:     bug-autom...@gnu.org



Hi,

the following line create a BUG in autoconf

# if 'CFLAGS' is NOT set, than macro 'AC_PROG_CC' set 'CFLAGS=-g -O2'

in seems that a M4-MACRO in COMMENT is a problem.

without this line… it works.

#   then increment AGE.
#
#    6. If any interfaces have been removed since the last public release,
#   then set AGE to 0.
#
# *_Never_* try to set the interface numbers so that they correspond
#  to the release number of your package.  This is an abuse that only
#  fosters misunderstanding of the purpose of library versions. Instead,
#  use the `-release' flag (*note Release numbers::), but be warned that
#  every release of your package will not be binary compatible with any
#  other release.
AC_SUBST([VERSION_INFO], [22:0:0])

AC_CONFIG_MACRO_DIR([m4])

# if 'CFLAGS' is NOT set, than macro 'AC_PROG_CC' set 'CFLAGS=-g -O2'
CFLAGS="-Wall -Wcast-align"
CXXFLAGS=""

AC_PROG_CC
AM_PROG_AR
AC_PROG_CXX
AC_PROG_CC_C99
if test "$ac_cv_prog_cc_c99" = "no"; then AC_MSG_ERROR([require c99 mode
to compile]); fi

if test "$build_os" != "cygwin"; then CFLAGS="-fvisibility=hidden
$CFLAGS"; fi
SC_ENABLE_THREADS

#
AC_MSG_CHECKING(get libtool support);echo
#
AC_DISABLE_STATIC
LT_INIT
LT_LIB_DLLOAD

#
AC_MSG_CHECKING(programs);echo
#
"configure.ac" 267L, 9761C geschrieben

#> autoconf
configure.ac:79: error: possibly undefined macro: AC_PROG_CC
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.

#> autoconf
#> autoconf

# autoconf -V
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>,
<http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.


mfg ao

Re: a bug in autoscan 2.69

[aquanox]

ok, thanks for your reply

发自网易邮箱大师


在2017年12月14日 06:49，Eric Blake 写道：
On 12/13/2017 03:35 PM, aquanox wrote:
> 1
> $ autoscan
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> 5.30), passed through in regex; marked by <-- HERE in m/\${ <-- HERE [^\}]*}/ 
> at /usr/bin/autoscan-2.69 line 361.

Thanks for the report.  This has already been fixed in git, and it is
just waiting for me to find time to release autoconf 2.70.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

bug fix: conftest.dSYM is not removed on Darwin

[Sam Steingold]

$ac_rmfiles may contain *.dSYM which is a directory on Darwin and thus
must be removed with `rm -rf` rather than `rm -f`.

>From 480332c9a91e882c444e55ae5e445869e7b143e3 Mon Sep 17 00:00:00 2001
From: Sam Steingold 
Date: Wed, 6 Dec 2017 12:24:25 -0500
Subject: [PATCH] ac_rmfiles must be removed with "rm -rf" because it includes
 dSYM directory on Darwin

---
 lib/autoconf/lang.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/autoconf/lang.m4 b/lib/autoconf/lang.m4
index 4ce403ba..3d41e665 100644
--- a/lib/autoconf/lang.m4
+++ b/lib/autoconf/lang.m4
@@ -534,7 +534,7 @@ do
 * ) ac_rmfiles="$ac_rmfiles $ac_file";;
   esac
 done
-rm -f $ac_rmfiles
+rm -f -r $ac_rmfiles
 
 AS_IF([_AC_DO_VAR(ac_link_default)],
 [# Autoconf-2.13 could set the ac_cv_exeext variable to `no'.
-- 
2.15.1


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://honestreporting.com http://no2bds.org http://mideasttruth.com
Good programmers treat Microsoft products as damage and route around it.

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

[Paul Eggert]

Václav Haisman wrote:

How buggy is FreeBSD's `mktime()`? Links, bugs?


See the mktime test program in gawk's 'configure' script. It probably comes 
from:

http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/mktime.m4

Some mktime implementations are quite bad: they can go into infinite or 
seemingly-infinite loops and/or dump core in addition to returning incorrect 
answers. I don't know which of the problems FreeBSD mktime has. You should be OK 
if you use glibc mktime, Gnulib mktime, or the reference mktime in tzcode.

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

[Eric Pruitt]

On Tue, Jul 25, 2017 at 08:44:30PM -0700, Paul Eggert wrote:
> > > Is there an additional flag I
> > > should pass to the configure script to make static linking work without
> > > modifying the configuration header?
>
> Yes, 'ac_cv_func_working_mktime=yes'.
>
> This will cause Gawk to use the FreeBSD mktime [...]

Thanks, that worked.

Eric

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

[Václav Haisman]

On 26 July 2017 at 05:44, Paul Eggert  wrote:
>>> Is there an additional flag I
>>> should pass to the configure script to make static linking work without
>>> modifying the configuration header?
>
>
> Yes, 'ac_cv_func_working_mktime=yes'.
>
> This will cause Gawk to use the FreeBSD mktime even though it is buggy.
> Quite possibly you won't notice the bugs.
>

How buggy is FreeBSD's `mktime()`? Links, bugs?

-- 
VH

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

[Paul Eggert]

Is there an additional flag I
should pass to the configure script to make static linking work without
modifying the configuration header?


Yes, 'ac_cv_func_working_mktime=yes'.

This will cause Gawk to use the FreeBSD mktime even though it is buggy. Quite 
possibly you won't notice the bugs.

Re: [bug-gawk] mktime(3) not detected on FreeBSD with -static

[arnold]

Hi.

Thanks for the report.

This is an issue in the Autoconf AC_FUNC_MKTIME macro which gawk uses.
I am forwarding this to the bug-autocof list, in the hope that they
can help.

I will try to add a README file in the gawk distribution about this
issue until there's a new Autoconf release that fixes it...

Thanks,

Arnold
---
Eric Pruitt <eric.pru...@gmail.com> wrote:

> When running ./configure for GAWK 4.1.4, the mktime(3) function is not
> detected on FreeBSD 11 when using -static with CFLAGS and LDFLAGS. This
> causes the build to fail:
>
> /usr/lib/libc.a(localtime.o): In function `mktime':
> /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:(.text+0x910): 
> multiple definition of `mktime'
>
> If I add "#define HAVE_MKTIME 1" to config.h, the build succeeds, and it
> also succeeds if I remove "-static" from CFLAGS and LDFLAGS. I'm using
> the default compiler on FreeBSD, "FreeBSD clang version 3.8.0". I have
> attached config.log to this message. Is there an additional flag I
> should pass to the configure script to make static linking work without
> modifying the configuration header?
>
> Thanks,
> Eric
>
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU Awk configure 4.1.4, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure CC=cc CFLAGS=-I/usr/home/user/suu/common/include -O3  -static 
-DREALLYMEAN LDFLAGS=-L/usr/home/user/suu/common/lib  -static 
--disable-extensions --disable-nls

## - ##
## Platform. ##
## - ##

hostname = freebsd
uname -m = amd64
uname -r = 11.0-RELEASE-p1
uname -s = FreeBSD
uname -v = FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC 

/usr/bin/uname -p = amd64
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /home/user/bin


## --- ##
## Core tests. ##
## --- ##

configure:2642: checking for a BSD-compatible install
configure:2710: result: ./install-sh -c
configure:2721: checking whether build environment is sane
configure:2776: result: yes
configure:2927: checking for a thread-safe mkdir -p
configure:2966: result: ./install-sh -c -d
configure:2973: checking for gawk
configure:3003: result: no
configure:2973: checking for mawk
configure:3003: result: no
configure:2973: checking for nawk
configure:2989: found /usr/bin/nawk
configure:3000: result: nawk
configure:3011: checking whether make sets $(MAKE)
configure:3033: result: yes
configure:3062: checking whether make supports nested variables
configure:3079: result: yes
configure:3247: checking build system type
configure:3261: result: x86_64-unknown-freebsd11.0
configure:3281: checking host system type
configure:3294: result: x86_64-unknown-freebsd11.0
configure:3326: checking for style of include used by make
configure:3354: result: GNU
configure:3425: checking for gcc
configure:3452: result: cc
configure:3681: checking for C compiler version
configure:3690: cc --version >&5
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
configure:3701: $? = 0
configure:3690: cc -v >&5
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
configure:3701: $? = 0
configure:3690: cc -V >&5
cc: error: argument to '-V' is missing (expected 1 value)
cc: error: no input files
configure:3701: $? = 1
configure:3690: cc -qversion >&5
cc: error: unknown argument: '-qversion'
cc: error: no input files
configure:3701: $? = 1
configure:3721: checking whether the C compiler works
configure:3743: cc -I/usr/home/user/suu/common/include -O3  -static 
-DREALLYMEAN  -L/usr/home/user/suu/common/lib  -static conftest.c  >&5
configure:3747: $? = 0
configure:3795: result: yes
configure:3798: checking for C compiler default output file name
configure:3800: result: a.out
configure:3806: checking for suffix of executables
configure:3813: cc -o conftest -I/usr/home/user/suu/common/include -O3  -static 
-DREALLYMEAN  -L/usr/home/user/suu/common/lib  -static conftest.c  >&5
configure:3817: $? = 0
configure:3839: result: 
configure:3861: checking whether we are cross compiling
configure:3869: cc -o conftest -I/usr/home/user/suu/common/include -O3  -static 
-DREALLYMEAN  -L/usr/home/user/suu/common/lib  -static conftest.c  >&5
config

Re: bug#20941: Fwd: installation of automake, autoconf, m4 error

[Mathieu Lirzin]

Hello,

Krishnan Rajiyah <kraji...@gmail.com> writes:

> -- Forwarded message -
> From: Krishnan Rajiyah <kraji...@gmail.com>
> Date: Mon, Jun 29, 2015 at 10:40 AM
> Subject: installation of automake, autoconf, m4 error
> To: <g...@gnu.org>, <bug...@gnu.org>
>
> Hello GNU,
>
> I have been trying to install automake, autoconf, and m4 on my 
> NetBSD-4.0.1-x68k system. As I understand from your website, automake 
> requires autoconf which requires m4 which requires perl. I havent
> installed perl yet, because I am getting errors saying that it cant make 
> built-in (still trying to find a way around this).
>
> However, the problem I had with m4 make was not with perl, it said that 
> automake-1.14 was missing from the system. This does not make sense since 
> that would mean that there would be a cycle in the
> dependency tree.
>
> I am trying to install the latest version of autoconf (2012 release), the 
> latest version of m4 (2013 release), and the second latest verison of 
> automake (2013 release).
>
> Can you please tell me what I am doing wrong? Is your software even 
> compatible with a NetBSD-4.0.1-x68k system?

When building a package from a tarball, Unless something fishy happened
in the distribution process, Automake should not be required.  Maybe you
were trying to build m4 from the git repository?  I have successfully
built m4-1.4.18 tarball on my system without requiring Automake.

Thanks for the bug report.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Bug in autogenerated 'autoscan' Perl script

[Eric Blake]

On 12/21/2016 08:36 AM, Eric Blake wrote:
> On 12/12/2016 12:07 AM, Ken Cotterill wrote:
>>I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan'
>>script which caused 'make check' to fail on test 503.
>>The statement causing the problem is:
>>s/\${[^\}]*}//g;
>>which was at line 361 in my version.
> 
> Thanks; I'll get that patched before autoconf 2.70 (which I hope to
> release this year).

In fact, the patch is already applied, and we are just waiting on the
release:

http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e5654

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Bug in autogenerated 'autoscan' Perl script

[Eric Blake]

On 12/12/2016 12:07 AM, Ken Cotterill wrote:
>I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan'
>script which caused 'make check' to fail on test 503.
>The statement causing the problem is:
>s/\${[^\}]*}//g;
>which was at line 361 in my version.

Thanks; I'll get that patched before autoconf 2.70 (which I hope to
release this year).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Bug in autogenerated 'autoscan' Perl script

[Ken Cotterill]

   I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan'
   script which caused 'make check' to fail on test 503.
   The statement causing the problem is:
   s/\${[^\}]*}//g;
   which was at line 361 in my version.
   The diagnostic message was:
   "Unescaped left brace in regex is deprecated, ..."
   You can search [1]perldiag for that string (without the "...") to see
   the full message and its explanation.
   That deprecation was intoduced in v5.22: "[2]perl5220delta: A literal
   "{" should now be escaped in a pattern".
   Furthermore, the right brace in the character class does not need to be
   escaped. See "[3]perlrecharclass: Special Characters Inside a Bracketed
   Character Class".
   So, that problem line would be better as:
   s/\$\{[^}]*}//g;
   I did a quick test to demonstrate those points:
   $ perl -v | head -2 | tail -1
   This is perl 5, version 24, subversion 0 (v5.24.0) built for
   darwin-thread-multi-2level
   $ perl -E 'say q/a${b}c/ =~ s/\${[^\}]*}//r'
   Unescaped left brace in regex is deprecated, passed through in regex;
   marked by <-- HERE in m/\${ <-- HERE [^\}]*}/ at -e line 1.
   ac
   $ perl -E 'say q/a${b}c/ =~ s/\$\{[^}]*}//r'
   ac
   I edited my version of the 'autoscan' script manually; reran 'make
   check'; it completed without further problems.
   Cheers,
   Ken.

References

   1. http://perldoc.perl.org/perldiag.html
   2. 
http://perldoc.perl.org/perl5220delta.html#A-literal-%22%7b%22-should-now-be-escaped-in-a-pattern
   3. 
http://perldoc.perl.org/perlrecharclass.html#Special-Characters-Inside-a-Bracketed-Character-Class

bug in AC_PROG_CXX

[Thorsten Schütt]

Hi,

I believe that there is a bug in the AC_PROG_CXX macro. Please find attached 
the reproducer including output and config.log.

I created a virtual machine with Fedora 24 with *no* C++ compiler, built the 
master of the autoconf git repository, and created a configure file from the 
configure.ac file (calling the new autooconf):

AC_INIT(repro, 0.1, schu...@zib.de)

AC_PROG_CXX

echo $CXX

According to the documentation: "If none of those checks succeed, then as a 
last resort set CXX to g++.” However, the configure file fails and stops before 
reaching the echo command.

checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking for clang++... no
checking whether the C++ compiler works... no
configure: error: in `/home/schuett/repro':
configure: error: C++ compiler cannot create executables
See `config.log' for more details

I am happy to provide more information if necessary.

Regards,
  Thorsten



repro.tgz
Description: Binary data

Re: Fwd: ax_lib_hdf5 bug with library ordering, static libraries

[Eric Blake]

On 08/30/2016 03:57 PM, Harald Anlauf wrote:
> 
> I have a system where HDF5 installation seems to differ from what the
> autoconf package ax_lib_hdf5 expects:
> 

Except that autoconf proper doesn't provide ax_lib_hdf5.  Given the ax_
prefix, it probably belongs to the Autoconf Archive project,
https://www.gnu.org/software/autoconf-archive/

I'm not sure if I have the correct bug reporting address for that
project, so I've added the maintainer address mentioned in the manual in cc.

> % h5fc -show
> gfortran -I/usr/include -L/usr/lib /usr/lib/libhdf5hl_fortran.a
> /usr/lib/libhdf5_hl.a /usr/lib/libhdf5_fortran.a /usr/lib/libhdf5.a
> -lpthread -lz -lrt -ldl -lm -Wl,-rpath -Wl,/usr/lib
> 
> Using the latest snapshot of ax_lib_hdf5, I get:
> 
> configure.in:
> 
> AX_LIB_HDF5([serial])
> echo "HDF5_LDFLAGS=$HDF5_LDFLAGS"
> echo "HDF5_FLIBS=$HDF5_FLIBS"
> echo "HDF5_FFLAGS=$HDF5_FFLAGS"
> 
> Running configure:
> 
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for gawk... gawk
> checking for h5cc... /usr/bin/h5cc
> checking for HDF5 type... serial
> checking for HDF5 libraries... yes (version 1.8.12)
> checking hdf5.h usability... yes
> checking hdf5.h presence... yes
> checking for hdf5.h... yes
> checking for H5Fcreate in -lhdf5... yes
> checking for main in -lhdf5_hl... yes
> checking for matching HDF5 Fortran wrapper... /usr/bin/h5fc
> HDF5_LDFLAGS=-L/usr/lib
> HDF5_FLIBS= -lm -ldl -lrt -lz -lpthread -lhdf5_fortran -lhdf5
> -lhdf5hl_fortran -lhdf5_hl
> HDF5_FFLAGS=-I/usr/lib -L/usr/lib -I/usr/include
> 
> The ordering of the libraries in HDF5_FLIB seems to get screwed up.
> I think the logic in rewriting the FLIB part in lines 270-308 is not
> prepared to handle my environment.
> 
> Is somebody still working on the HDF5 support?
> 
> Thanks,
> Harald
> 
> 
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Fwd: ax_lib_hdf5 bug with library ordering, static libraries

[Harald Anlauf]

[I erroneously mailed this to the autoconf list.  Sorry for that.]

Hello,

I have a system where HDF5 installation seems to differ from what the
autoconf package ax_lib_hdf5 expects:

% h5fc -show
gfortran -I/usr/include -L/usr/lib /usr/lib/libhdf5hl_fortran.a
/usr/lib/libhdf5_hl.a /usr/lib/libhdf5_fortran.a /usr/lib/libhdf5.a
-lpthread -lz -lrt -ldl -lm -Wl,-rpath -Wl,/usr/lib

Using the latest snapshot of ax_lib_hdf5, I get:

configure.in:

AX_LIB_HDF5([serial])
echo "HDF5_LDFLAGS=$HDF5_LDFLAGS"
echo "HDF5_FLIBS=$HDF5_FLIBS"
echo "HDF5_FFLAGS=$HDF5_FFLAGS"

Running configure:

checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... gawk
checking for h5cc... /usr/bin/h5cc
checking for HDF5 type... serial
checking for HDF5 libraries... yes (version 1.8.12)
checking hdf5.h usability... yes
checking hdf5.h presence... yes
checking for hdf5.h... yes
checking for H5Fcreate in -lhdf5... yes
checking for main in -lhdf5_hl... yes
checking for matching HDF5 Fortran wrapper... /usr/bin/h5fc
HDF5_LDFLAGS=-L/usr/lib
HDF5_FLIBS= -lm -ldl -lrt -lz -lpthread -lhdf5_fortran -lhdf5
-lhdf5hl_fortran -lhdf5_hl
HDF5_FFLAGS=-I/usr/lib -L/usr/lib -I/usr/include

The ordering of the libraries in HDF5_FLIB seems to get screwed up.
I think the logic in rewriting the FLIB part in lines 270-308 is not
prepared to handle my environment.

Is somebody still working on the HDF5 support?

Thanks,
Harald

Re: Bug in ax_cflags_warn_all on DEC/Compaq Tru64

[Mike Frysinger]

On 26 Jun 2016 13:29, Jeffrey Armstrong wrote:
> I've run across a bug in the script ax_cflags_warn_all.m4 when testing on 

all the ax_* files are maintained in a diff GNU project.  this autoconf
list is just for the core autoconf package itself and not the third party
library projects.  in this case, the GNU Autoconf Archive project is the
one you seek:
https://www.gnu.org/software/autoconf-archive/
autoconf-archive-maintain...@gnu.org

if you have a patch already, you can submit a PR directly:
https://github.com/peti/autoconf-archive
-mike


signature.asc
Description: Digital signature

Bug in ax_cflags_warn_all on DEC/Compaq Tru64

[Jeffrey Armstrong]

I've run across a bug in the script ax_cflags_warn_all.m4 when testing on 
Tru64 (OSF/1) when using the Compaq C (previously Digital C) compiler. 
The script is meant to determine which flags to use to enable all 
warnings.  On the platform described, it always selects the Intel flags 
for a very odd reason.


Compaq C, when it encounters an unknown flag starting with either "W" or 
"w," passes the flag to the linker when linking is requested.  If the user 
is just compiling, no action is taken.  Therefore, the C compiler will 
accept the flags "-warn all" which is Intel-specific.  However, if linking 
were requested, an error is raised correctly.


In order to properly test the Compaq C compiler's accepted flag, linking 
has to be tested as well.  Based on the most up-to-date version of 
ax_cflags_warn_all.m4, changing lines 81-82 from:


AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
 [VAR=`echo $ac_arg | sed -e 's,.*% *,,'` ; break])

to:

AC_LINK_IFELSE([AC_LANG_PROGRAM],
 [VAR=`echo $ac_arg | sed -e 's,.*% *,,'` ; break])

fixes the problem for Compaq C without actually causing any further 
problems on other compilers.  A simple patch is included.


I realize Compaq C is a niche and obsolete system at this point, but the 
fix is neccesary to support the compiler.


I appreciate your time, and please let me know if I can provide any 
further information.



Jeff Armstrong - j...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org--- a/ax_cflags_warn_all.m4 2016-06-26 09:27:28.859816334 -0400
+++ b/ax_cflags_warn_all.m4 2016-06-26 09:24:33.240950362 -0400
@@ -78,7 +78,7 @@
"-h conform % -h msglevel 2" dnl Cray C (Unicos)
#
 do FLAGS="$ac_save_[]FLAGS "`echo $ac_arg | sed -e 's,%%.*,,' -e 's,%,,'`
-   AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
+   AC_LINK_IFELSE([AC_LANG_PROGRAM],
  [VAR=`echo $ac_arg | sed -e 's,.*% *,,'` ; break])
 done
 FLAGS="$ac_save_[]FLAGS"

Re: Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC

[Paul Eggert]

On 02/22/2016 01:46 PM, Dwight Guth wrote:

Currently there is a problem with the way the AC_C_RESTRICT macro behaves
if you are using GLIBC with a C99-compliant compiler that does not define
the __GNUC__ macro, but does define __restrict.


Which compiler is this, exactly? What does it define __restrict to?


I believe that glibc's behavior is also wrong in this case, but even if glibc
were to do the correct thing and define __restrict to the keyword, you
would still have a bug in autoconf caused by a circular define. You can't
see this in the case with gcc, but if another compiler were to define
__restrict as a macro but not a keyword, this would then cause compilation
to crash whenever the __restrict keyword is used, because the circular
define would prevent macro replacement, __restrict would not be a keyword.


Sorry, I'm not getting the scenario. Another compiler would define a 
macro for __restrict? Why would it bother? It can implement __restrict 
directly.



I'm pretty sure that the way you want to handle this is that if __restrict
is preprocessed into "foo", then config.h should define "restrict" as "foo"
instead of as "__restrict".


We have no portable way to deduce what a macro expands to, for arbitrary 
compilers.


Perhaps we can do something for your particular case, but we'd need to 
know more about it.

Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC

[Dwight Guth]

Currently there is a problem with the way the AC_C_RESTRICT macro behaves
if you are using GLIBC with a C99-compliant compiler that does not define
the __GNUC__ macro, but does define __restrict. You can see this for
yourself by passing `CFLAGS="-U __GNUC__"` to a configure script that uses
it. Autoconf defines the restrict keyword to __restrict, because it detects
that this keyword exists. However, glibc defines away the __restrict
keyword to empty in this case. This leads the restrict keyword being
removed in all cases even though the compiler treats it as a valid keyword.
Attached is my testsuite.log file for information about my environment. I
believe that glibc's behavior is also wrong in this case, but even if glibc
were to do the correct thing and define __restrict to the keyword, you
would still have a bug in autoconf caused by a circular define. You can't
see this in the case with gcc, but if another compiler were to define
__restrict as a macro but not a keyword, this would then cause compilation
to crash whenever the __restrict keyword is used, because the circular
define would prevent macro replacement, __restrict would not be a keyword.

I'm pretty sure that the way you want to handle this is that if __restrict
is preprocessed into "foo", then config.h should define "restrict" as "foo"
instead of as "__restrict".
## - ##
## GNU Autoconf 2.69 test suite. ##
## - ##

testsuite: command line was:
  $ ./testsuite 

## -- ##
## ChangeLog. ##
## -- ##

| 2012-04-24  Eric Blake  <ebl...@redhat.com>
| 
| 	Release Version 2.69.
| 	* NEWS: Mention the release.
| 
| 2012-04-24  Eric Blake  <ebl...@redhat.com>
| 
| 	maint: drop bz2 tarball
| 	At 2.68b, I asked whether anyone would miss .gz and .bz2 formats.
| 	Consensus was overwhelming that .gz still holds a place in people's

## - ##
## Platform. ##
## - ##

hostname = rvwork-1
uname -m = x86_64
uname -r = 3.19.0-31-generic
uname -s = Linux
uname -v = #36~14.04.1-Ubuntu SMP Thu Oct 8 10:21:08 UTC 2015

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/dwightguth/autoconf-2.69/tests
PATH: /home/dwightguth/.opam/4.03.0+k/bin
PATH: /home/dwightguth/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games
PATH: /usr/local/texlive/2014/bin/x86_64-linux
PATH: /home/dwightguth/cil-1.3.7/bin
PATH: /home/dwightguth/c-semantics/dist
PATH: /home/dwightguth/k/k-distribution/target/release/k/bin
PATH: /opt/eclipse

testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2012 Free Software Foundation, Inc.
| 
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/home/dwightguth/autoconf-2.69/tests'
| at_srcdir='.'
| abs_srcdir='/home/dwightguth/autoconf-2.69/tests'
| at_top_srcdir='..'
| abs_top_srcdir='/home/dwightguth/autoconf-2.69'
| at_top_build_prefix='../'
| abs_top_builddir='/home/dwightguth/autoconf-2.69'
| 
| # Backward compatibility with Autotest <= 2.59b:
| at_top_builddir=$at_top_build_prefix
| 
| AUTOTEST_PATH='tests'
| 
| SHELL=${CONFIG_SHELL-'/bin/bash'}

testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal.  Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| 
| # Copyright (C) 2000-2001, 2005, 2008-2012 Free Software Foundation,
| # Inc.
| #
| # This program is free software: you can redistribute it and/or modify
| # it under the terms of the GNU General Public License as published by
| # the Free Software Foundation, either version 3 of the License, or
| # (at your option) any later version.
| #
| # This program is distributed in the hope that it will be useful,
| # but WITHOUT ANY WARRANTY; without even the implied warranty of
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| # GNU General Public License for more details.
| #
| # You should have received a copy of the GNU General Public License
| # along with this program.  If not, see <http://www.gnu.org/licenses/>.
| 
| PERL='/usr/bin/perl'
| GREP='/bin/grep'
| EGREP='/bin/grep -E'
| SED='/bin/sed'
| 
| # We need to know if sh -n is ok.
| ac_cv_sh_n_works='no'
| 
| # Check whether the underlying system can manage some unusual
| # symbols in file names.
| if test -z ''; then
|   func_sanitize_file_name () { echo "$@"; }
| else
|   func_sanitize_file_name () { echo "$@" | tr -d ''; }
| fi
| 
| # Can we create directories with trailing whitespace in their names?
| ac_cv_dir_trailing_space='yes'
| if test 

mmm-mode configure hangs because of autoconf bug

[Jauhien Piatlicki]

Hi,

on my Gentoo system autogenerated configure script for mmm-mode
(http://mmm-mode.sourceforge.net/) hangs because configure script
generated by autoconf calls emacs without '--no-site-file' flag.

The call that configure makes looks like this:

sudo emacs -batch -q -eval '(while load-path (princ (concat (car
load-path) "\n")) (setq load-path (cdr load-path)))'

and it hangs on

Opening output file: no such file or directory,
/root/.emacs.d/.smex-items

The call

sudo emacs -batch -q --no-site-file -eval '(while load-path (princ
(concat (car load-path) "\n")) (setq load-path (cdr load-path)))'

succeds. It is a bug in the sys-devel/autoconf and can not be fixed by
patching configure.in as autoconf itself generates wrong call to emacs.

Configure and configure.in are attached.

See also https://bugs.gentoo.org/show_bug.cgi?id=561306

Regards,
Jauhien Piatlicki

#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.69.
#
#
# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
#
#
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
##  ##
## M4sh Initialization. ##
##  ##

# Be more Bourne compatible
DUALCASE=1; export DUALCASE # for MKS sh
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
  emulate sh
  NULLCMD=:
  # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
  # is contrary to our usage.  Disable this feature.
  alias -g '${1+"$@"}'='"$@"'
  setopt NO_GLOB_SUBST
else
  case `(set -o) 2>/dev/null` in #(
  *posix*) :
set -o posix ;; #(
  *) :
 ;;
esac
fi


as_nl='
'
export as_nl
# Printing a long string crashes Solaris 7 /usr/bin/printf.
as_echo='\\\'
as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
# Prefer a ksh shell builtin over an external printf program on Solaris,
# but without wasting forks for bash or zsh.
if test -z "$BASH_VERSION$ZSH_VERSION" \
&& (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
  as_echo='print -r --'
  as_echo_n='print -rn --'
elif (test "X`printf %s $as_echo`" = "X$as_echo") 2>/dev/null; then
  as_echo='printf %s\n'
  as_echo_n='printf %s'
else
  if test "X`(/usr/ucb/echo -n -n $as_echo) 2>/dev/null`" = "X-n $as_echo"; then
as_echo_body='eval /usr/ucb/echo -n "$1$as_nl"'
as_echo_n='/usr/ucb/echo -n'
  else
as_echo_body='eval expr "X$1" : "X\\(.*\\)"'
as_echo_n_body='eval
  arg=$1;
  case $arg in #(
  *"$as_nl"*)
expr "X$arg" : "X\\(.*\\)$as_nl";
arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
  esac;
  expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
'
export as_echo_n_body
as_echo_n='sh -c $as_echo_n_body as_echo'
  fi
  export as_echo_body
  as_echo='sh -c $as_echo_body as_echo'
fi

# The user is always right.
if test "${PATH_SEPARATOR+set}" != set; then
  PATH_SEPARATOR=:
  (PATH='/bin;/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 && {
(PATH='/bin:/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 ||
  PATH_SEPARATOR=';'
  }
fi


# IFS
# We need space, tab and new line, in precisely that order.  Quoting is
# there to prevent editors from complaining about space-tab.
# (If _AS_PATH_WALK were called with IFS unset, it would disable word
# splitting by setting IFS to empty value.)
IFS=" ""$as_nl"

# Find who we are.  Look in the path if we contain no directory separator.
as_myself=
case $0 in #((
  *[\\/]* ) as_myself=$0 ;;
  *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
  IFS=$as_save_IFS
  test -z "$as_dir" && as_dir=.
test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
  done
IFS=$as_save_IFS

 ;;
esac
# We did not find ourselves, most probably we were run as `sh COMMAND'
# in which case we are not to be found in the path.
if test "x$as_myself" = x; then
  as_myself=$0
fi
if test ! -f "$as_myself"; then
  $as_echo "$as_myself: error: cannot find myself; rerun with an absolute file 
name" >&2
  exit 1
fi

# Unset variables that we do not need and which cause bugs (e.g. in
# pre-3.0 UWIN ksh).  But do not cause bugs in bash 2.01; the "|| exit 1"
# suppresses any "Segmentation fault" message there.  '((' could
# trigger a bug in pdksh 5.2.14.
for as_var in BASH_ENV ENV MAIL MAILPATH
do eval test x\${$as_var+set} = x

RE: Autoconf 2.69 bug

[Steve Glaser]

That's fine. It was pretty easy to work around. Other stuff gets confused by 
Dropbox's convention. I've told them I'm not wild about it.

Just wanted to mention it in case it was something you wanted to look at.

I'll see if anyone on the SystemC forum claims ownership.

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Tuesday, September 01, 2015 1:46 PM
> To: Steve Glaser; bug-autoconf@gnu.org
> Cc: sgla...@sglaser.com
> Subject: Re: Autoconf 2.69 bug
> 
> * PGP Signed by an unknown key
> 
> > I created a symbolic link /Users/login/Dropbox-Company to
> /Users/login/Dropbox (Company). When I build in that area, things work as
> expected.
> 
> Then this is what you should do. :)
> 
> >
> > I suspect there's some place that needs double quotes. I don't know whether
> it's in your stuff or in the SystemC customization.
> 
> Autoconf tries to allow for absolute paths that contain spaces and other shell
> metacharacters, as long as the build tree itself does not add any further; 
> but it
> may not always succeed (patches welcome).  But even if autoconf is perfect in
> its use of quoting, many other packages write configure.ac that are not as
> careful.  In this regards, I suspect that it is the SystemC code at fault for 
> not
> handling metacharacters in the absolute path.  In fact, it may be an unfixable
> problem; the 'make'
> language is very unforgiving in its syntax (it lacks double quotes that shell 
> has),
> and any project that uses automake in addition to autoconf to generate the
> configure/Makefile pairs may result in a generated Makefile that cannot deal
> with absolute paths that aren't sane.
> 
> So unless you can point to a specific error message, and prove that it comes
> from autoconf proper and not from SystemC's configure.ac file, I'm inclined to
> think this is not an autoconf bug, but a normal limitation that you'll just 
> have to
> work around via symlink or mount point.
> 
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
> 
> * Unknown Key
> * 0x2527436A

Autoconf 2.69 bug

[Steve Glaser]

I was building SystemC on OSX Yosemite (10.10.5) in my Dropbox area. Because I 
have both a personal and a corporate Dropbox account, the default names for the 
directories are:

/Users/login/Dropbox (Personal)
/Users/login/Dropbox (Company)

If I extract SystemC into a fresh subdirectory of one of those and try to 
build, it barfs. I didn't look into the exact error, but it's related to the 
space and/or '(' in the directory path.

I created a symbolic link /Users/login/Dropbox-Company to /Users/login/Dropbox 
(Company). When I build in that area, things work as expected.

I suspect there's some place that needs double quotes. I don't know whether 
it's in your stuff or in the SystemC customization. You can download SystemC 
from http://accellera.org/images/downloads/standards/systemc/systemc-2.3.1.tgz. 
It's open source.

I've posted an issue in the SystemC forum as well... 
(http://forums.accellera.org/topic/5006-systemc-install-dropbox-in-pathname/)

Re: Autoconf 2.69 bug

[Eric Blake]

> I created a symbolic link /Users/login/Dropbox-Company to 
> /Users/login/Dropbox (Company). When I build in that area, things work as 
> expected.

Then this is what you should do. :)

> 
> I suspect there's some place that needs double quotes. I don't know whether 
> it's in your stuff or in the SystemC customization.

Autoconf tries to allow for absolute paths that contain spaces and other
shell metacharacters, as long as the build tree itself does not add any
further; but it may not always succeed (patches welcome).  But even if
autoconf is perfect in its use of quoting, many other packages write
configure.ac that are not as careful.  In this regards, I suspect that
it is the SystemC code at fault for not handling metacharacters in the
absolute path.  In fact, it may be an unfixable problem; the 'make'
language is very unforgiving in its syntax (it lacks double quotes that
shell has), and any project that uses automake in addition to autoconf
to generate the configure/Makefile pairs may result in a generated
Makefile that cannot deal with absolute paths that aren't sane.

So unless you can point to a specific error message, and prove that it
comes from autoconf proper and not from SystemC's configure.ac file, I'm
inclined to think this is not an autoconf bug, but a normal limitation
that you'll just have to work around via symlink or mount point.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#20733: coreutils build problem

[Eric Blake]

On 06/05/2015 04:45 AM, Michael Felt wrote:

[we tend to avoid top-posting on technical lists, as it makes it harder
to follow the flow of the message]

 My fear is that autoconf has introduced this catch-all as I have been
 running into it more frequently of late (first time was last November when
 I took my first attempt at packaging gcc.)
 

Paul's patch was specific to a coreutils file.  So far, I have not seen
any evidence of autoconf introducing 'for x in ;' anywhere in configure.
 If you are seeing the same problem in multiple packages, so far it is
because each package has made a similar mistake in their local
configuration files.

 I shall look at the patch and let you know - however, regardless of whether
 it works or not - is this something that autoconf is introducing, read
 changed - requiring you to make a patch. If so, while from autoconf
 perspective all may be well - it is not very user-friendly. (I just do not
 understand autoconf well enough to make that distinction).

If the syntax error is in autoconf.ac or in Makefile.am, then it is the
package that wrote the file at fault.  If the syntax error is not in
anything the package provides, but appears in the generated configure
file, then it is more likely to be in automake or autoconf.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#20733: coreutils build problem

[Michael Felt]

I think I still have automake 1.14 lying around, but would be nice if
automake-1.15 would have just accepted the patch :)

*Most important - the patch seems to be working!* At least I got farther...

On my bare system - initially NO extras installed to find 'hard', i.e.,
real dependencies.

root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
  GEN  lib/alloca.h
  GEN  lib/arpa/inet.h
  GEN  ./src/single-binary.mk
 cd .  /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
automake-1.14 --gnu Makefile
/data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
automake-1.14:  not found.
WARNING: 'automake-1.14' is missing on your system.
 You should only need it if you modified 'Makefile.am' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'automake' program is part of the GNU Automake package:
 http://www.gnu.org/software/automake
 It also requires GNU Autoconf, GNU m4 and Perl in order to run:
 http://www.gnu.org/software/autoconf
 http://www.gnu.org/software/m4/
 http://www.perl.org/
make: 1254-004 The error code from the last command is 127.

So, on my more loaded system - x064 - (with other tools, i.e.)
root@x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
configure.ac:35: error: version mismatch.  This is Automake 1.15,
configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:35: comes from Automake 1.14.1.  You should recreate
configure.ac:35: aclocal.m4 with aclocal and run automake again.

After loading automake 1.14.1 and running automake - got farther still,

root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
 cd .  /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
  GEN  lib/configmake.h
  GEN  lib/ctype.h
  GEN  lib/dirent.h
  GEN  lib/errno.h
  GEN  lib/fcntl.h
  GEN  lib/float.h
  GEN  lib/fnmatch.h
  GEN  lib/getopt.h
  GEN  lib/iconv.h
  GEN  lib/inttypes.h
  GEN  lib/langinfo.h
  GEN  lib/locale.h
  GEN  lib/math.h
  GEN  lib/netdb.h
  GEN  lib/selinux/selinux.h
  GEN  lib/selinux/context.h
  GEN  lib/signal.h
  GEN  lib/stdalign.h
  GEN  lib/stdint.h
  GEN  lib/stdio.h
  GEN  lib/stdlib.h
  GEN  lib/string.h
  GEN  lib/sys/ioctl.h
  GEN  lib/sys/resource.h
  GEN  lib/sys/select.h
  GEN  lib/sys/socket.h
  GEN  lib/sys/stat.h
  GEN  lib/sys/time.h
  GEN  lib/sys/types.h
  GEN  lib/sys/uio.h
  GEN  lib/sys/utsname.h
  GEN  lib/sys/wait.h
  GEN  lib/termios.h
  GEN  lib/time.h
  GEN  lib/unistd.h
  GEN  lib/wchar.h
  GEN  lib/wctype.h
  GEN  src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.

Shall rerun ./configure and see if the ./src directory problem is solved as
well (after automake)

p.s.
I do this packaging as root - so I always need to
# export  FORCE_UNSAFE_CONFIGURE=1

Would be more friendly if this check could be reported earlier in
./configure rather than just before it finishes.

On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt mamf...@gmail.com wrote:

 FYI: AIX - not Solaris - but old-school UNIX in both cases.

 And, yes - it is /bin/sh - which is the 'Bourne shell behavior iirc,
 rather than ksh behavior, but the program is the default AIX (not solaris)
 ksh (see inode #)

   26 -r-xr-xr-x 15 bin  bin 1457 May 14  2012 hash
   58 -r-xr-sr-x  1 root security   37092 Apr 25  2014 chsh
  148 lrwxrwxrwx  1 root system28 Feb  6 13:50 fcinit.sh -
 /usr/sbin/rsct/bin/fcinit.sh
  149 lrwxrwxrwx  1 root system29 Feb  6 13:50 fcinit.csh -
 /usr/sbin/rsct/bin/fcinit.csh
  263 -r-xr-s---  1 root system  5884 Mar  7  2014 refresh
  331 -r-xr-xr-x  1 bin  bin  918 May 14  2012 recsh
  443 -r-xr-xr-x  1 bin  bin   185344 Mar  7  2014 csh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 Rsh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 bsh
  540 -rwxr-xr-x  1 root system  4690 May  6  2013 c_rehash
  631 lrwxrwxrwx  1 bin  bin   16 Dec 20 16:21 dsh -
 /opt/csm/bin/dsh
  829 -r-xr-xr-x  1 bin  bin   287458 Mar 12  2013 msh
  845 lrwxrwxrwx  1 root system46 Dec 20 16:21 perfpmr.sh -
 /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
  907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 remsh
  907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 rsh
  983 lrwxrwxrwx  1 root system17 Dec 20 16:21 tclsh -
 /usr/bin/tclsh8.4
  986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 ksh
  986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 psh
  986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 rksh
  986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 sh
  986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 tsh
 1031 lrwxrwxrwx  1 root system16 Dec 20 16:21 wish -
 

Re: bug#20733: coreutils build problem

[Michael Felt]

an incremental build - isn't that what applying a patch to an official
release is. A fresh checkout is 'all patches' and difficult to replicate,
once another patch is applied.

Or I am just too old of a dog and having trouble learning this new trick :)

As far as above is concerned - I had automake 1.15 installed. I removed it
and installed automake-1.14.1 and the 'complaint' went away when I ran
automake.

On Fri, Jun 5, 2015 at 3:08 PM, Eric Blake ebl...@redhat.com wrote:

 On 06/05/2015 05:13 AM, Michael Felt wrote:
  I think I still have automake 1.14 lying around, but would be nice if
  automake-1.15 would have just accepted the patch :)
 
  *Most important - the patch seems to be working!* At least I got
 farther...
 
  On my bare system - initially NO extras installed to find 'hard', i.e.,
  real dependencies.
 
  root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
GEN  lib/alloca.h
GEN  lib/arpa/inet.h
GEN  ./src/single-binary.mk
   cd .  /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
  automake-1.14 --gnu Makefile
  /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
  automake-1.14:  not found.
  WARNING: 'automake-1.14' is missing on your system.

 That says you are doing an incremental build, but have updated automake
 in the meantime.  Do 'autoreconf -f' to pick up the new automake version
 into your generated Makefile.in files, and it should fix this issue.

 A fresh checkout rather than an incremental build would also work.

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

Re: bug#20733: coreutils build problem

[Michael Felt]

After rerunning ./configure --prefix=/opt I still stop at:

  GEN  src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.



On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt mamf...@gmail.com wrote:

 I think I still have automake 1.14 lying around, but would be nice if
 automake-1.15 would have just accepted the patch :)

 *Most important - the patch seems to be working!* At least I got
 farther...

 On my bare system - initially NO extras installed to find 'hard', i.e.,
 real dependencies.

 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
   GEN  lib/alloca.h
   GEN  lib/arpa/inet.h
   GEN  ./src/single-binary.mk
  cd .  /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
 automake-1.14 --gnu Makefile
 /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
 automake-1.14:  not found.
 WARNING: 'automake-1.14' is missing on your system.
  You should only need it if you modified 'Makefile.am' or
  'configure.ac' or m4 files included by 'configure.ac'.
  The 'automake' program is part of the GNU Automake package:
  http://www.gnu.org/software/automake
  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
  http://www.gnu.org/software/autoconf
  http://www.gnu.org/software/m4/
  http://www.perl.org/
 make: 1254-004 The error code from the last command is 127.

 So, on my more loaded system - x064 - (with other tools, i.e.)
 root@x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
 configure.ac:35: error: version mismatch.  This is Automake 1.15,
 configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
 configure.ac:35: comes from Automake 1.14.1.  You should recreate
 configure.ac:35: aclocal.m4 with aclocal and run automake again.

 After loading automake 1.14.1 and running automake - got farther still,

 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
  cd .  /bin/sh ./config.status Makefile depfiles
 config.status: creating Makefile
 config.status: executing depfiles commands
   GEN  lib/configmake.h
   GEN  lib/ctype.h
   GEN  lib/dirent.h
   GEN  lib/errno.h
   GEN  lib/fcntl.h
   GEN  lib/float.h
   GEN  lib/fnmatch.h
   GEN  lib/getopt.h
   GEN  lib/iconv.h
   GEN  lib/inttypes.h
   GEN  lib/langinfo.h
   GEN  lib/locale.h
   GEN  lib/math.h
   GEN  lib/netdb.h
   GEN  lib/selinux/selinux.h
   GEN  lib/selinux/context.h
   GEN  lib/signal.h
   GEN  lib/stdalign.h
   GEN  lib/stdint.h
   GEN  lib/stdio.h
   GEN  lib/stdlib.h
   GEN  lib/string.h
   GEN  lib/sys/ioctl.h
   GEN  lib/sys/resource.h
   GEN  lib/sys/select.h
   GEN  lib/sys/socket.h
   GEN  lib/sys/stat.h
   GEN  lib/sys/time.h
   GEN  lib/sys/types.h
   GEN  lib/sys/uio.h
   GEN  lib/sys/utsname.h
   GEN  lib/sys/wait.h
   GEN  lib/termios.h
   GEN  lib/time.h
   GEN  lib/unistd.h
   GEN  lib/wchar.h
   GEN  lib/wctype.h
   GEN  src/coreutils.h
 /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 make: 1254-004 The error code from the last command is 2.

 Shall rerun ./configure and see if the ./src directory problem is solved
 as well (after automake)

 p.s.
 I do this packaging as root - so I always need to
 # export  FORCE_UNSAFE_CONFIGURE=1

 Would be more friendly if this check could be reported earlier in
 ./configure rather than just before it finishes.

 On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt mamf...@gmail.com wrote:

 FYI: AIX - not Solaris - but old-school UNIX in both cases.

 And, yes - it is /bin/sh - which is the 'Bourne shell behavior iirc,
 rather than ksh behavior, but the program is the default AIX (not solaris)
 ksh (see inode #)

   26 -r-xr-xr-x 15 bin  bin 1457 May 14  2012 hash
   58 -r-xr-sr-x  1 root security   37092 Apr 25  2014 chsh
  148 lrwxrwxrwx  1 root system28 Feb  6 13:50 fcinit.sh -
 /usr/sbin/rsct/bin/fcinit.sh
  149 lrwxrwxrwx  1 root system29 Feb  6 13:50 fcinit.csh -
 /usr/sbin/rsct/bin/fcinit.csh
  263 -r-xr-s---  1 root system  5884 Mar  7  2014 refresh
  331 -r-xr-xr-x  1 bin  bin  918 May 14  2012 recsh
  443 -r-xr-xr-x  1 bin  bin   185344 Mar  7  2014 csh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 Rsh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 bsh
  540 -rwxr-xr-x  1 root system  4690 May  6  2013 c_rehash
  631 lrwxrwxrwx  1 bin  bin   16 Dec 20 16:21 dsh -
 /opt/csm/bin/dsh
  829 -r-xr-xr-x  1 bin  bin   287458 Mar 12  2013 msh
  845 lrwxrwxrwx  1 root system46 Dec 20 16:21 perfpmr.sh -
 /data/prj/labserv/perf61-2014.04.30/perfpmr.sh
  907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 remsh
  907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 rsh
  983 lrwxrwxrwx  1 root system17 Dec 20 16:21 tclsh -
 

Re: bug#20733: coreutils build problem

[Michael Felt]

My fear is that autoconf has introduced this catch-all as I have been
running into it more frequently of late (first time was last November when
I took my first attempt at packaging gcc.)

I shall look at the patch and let you know - however, regardless of whether
it works or not - is this something that autoconf is introducing, read
changed - requiring you to make a patch. If so, while from autoconf
perspective all may be well - it is not very user-friendly. (I just do not
understand autoconf well enough to make that distinction).

Thanks for looking! and listening!!

On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake ebl...@redhat.com wrote:

 [adding autoconf]

 On 06/04/2015 01:17 PM, Paul Eggert wrote:
 
  On 06/04/2015 09:41 AM, Michael Felt wrote:
GEN  src/coreutils.h
  /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 

  Port to POSIX shell, which doesn't allow 'for i in ; do ...'.

 Actually, POSIX _does_ allow for missing words between 'in' and the
 terminator (; or newline) before 'do' (whether by a word that expands to
 nothing, or by omission of words), requiring that the body of the for
 statement is skipped in that case:


 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04

 But it is also true that older shells did not always follow this rule,
 so you are indeed better off always supplying at least one word that
 won't be expanded into nothingness.

 Hmmm, I thought that autoconf would document it as a portability
 pitfall, but I don't see it under 'for' in this link:


 https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

Re: bug#20733: coreutils build problem

[Michael Felt]

Actually, looking at this more closely - before make did not do anything in
./lib initially - now it starts there, and it still comes to a halt with
GEN src/coreutils.h

Funny how the lib stuff can be generated without src/coreutils.h - is that
by design? I shall go back two steps (remove all, unpack, patch, automake,
and see where/how things go).

Michael

On Fri, Jun 5, 2015 at 1:16 PM, Michael Felt mamf...@gmail.com wrote:

 After rerunning ./configure --prefix=/opt I still stop at:

   GEN  src/coreutils.h
 /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 make: 1254-004 The error code from the last command is 2.



 On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt mamf...@gmail.com wrote:

 I think I still have automake 1.14 lying around, but would be nice if
 automake-1.15 would have just accepted the patch :)

 *Most important - the patch seems to be working!* At least I got
 farther...

 On my bare system - initially NO extras installed to find 'hard', i.e.,
 real dependencies.

 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
   GEN  lib/alloca.h
   GEN  lib/arpa/inet.h
   GEN  ./src/single-binary.mk
  cd .  /bin/sh /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing
 automake-1.14 --gnu Makefile
 /data/prj/gnu/coreutils/coreutils-8.23/build-aux/missing[81]:
 automake-1.14:  not found.
 WARNING: 'automake-1.14' is missing on your system.
  You should only need it if you modified 'Makefile.am' or
  'configure.ac' or m4 files included by 'configure.ac'.
  The 'automake' program is part of the GNU Automake package:
  http://www.gnu.org/software/automake
  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
  http://www.gnu.org/software/autoconf
  http://www.gnu.org/software/m4/
  http://www.perl.org/
 make: 1254-004 The error code from the last command is 127.

 So, on my more loaded system - x064 - (with other tools, i.e.)
 root@x064:[/data/prj/gnu/coreutils/coreutils-8.23]automake
 configure.ac:35: error: version mismatch.  This is Automake 1.15,
 configure.ac:35: but the definition used by this AM_INIT_AUTOMAKE
 configure.ac:35: comes from Automake 1.14.1.  You should recreate
 configure.ac:35: aclocal.m4 with aclocal and run automake again.

 After loading automake 1.14.1 and running automake - got farther still,

 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make
  cd .  /bin/sh ./config.status Makefile depfiles
 config.status: creating Makefile
 config.status: executing depfiles commands
   GEN  lib/configmake.h
   GEN  lib/ctype.h
   GEN  lib/dirent.h
   GEN  lib/errno.h
   GEN  lib/fcntl.h
   GEN  lib/float.h
   GEN  lib/fnmatch.h
   GEN  lib/getopt.h
   GEN  lib/iconv.h
   GEN  lib/inttypes.h
   GEN  lib/langinfo.h
   GEN  lib/locale.h
   GEN  lib/math.h
   GEN  lib/netdb.h
   GEN  lib/selinux/selinux.h
   GEN  lib/selinux/context.h
   GEN  lib/signal.h
   GEN  lib/stdalign.h
   GEN  lib/stdint.h
   GEN  lib/stdio.h
   GEN  lib/stdlib.h
   GEN  lib/string.h
   GEN  lib/sys/ioctl.h
   GEN  lib/sys/resource.h
   GEN  lib/sys/select.h
   GEN  lib/sys/socket.h
   GEN  lib/sys/stat.h
   GEN  lib/sys/time.h
   GEN  lib/sys/types.h
   GEN  lib/sys/uio.h
   GEN  lib/sys/utsname.h
   GEN  lib/sys/wait.h
   GEN  lib/termios.h
   GEN  lib/time.h
   GEN  lib/unistd.h
   GEN  lib/wchar.h
   GEN  lib/wctype.h
   GEN  src/coreutils.h
 /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 make: 1254-004 The error code from the last command is 2.

 Shall rerun ./configure and see if the ./src directory problem is solved
 as well (after automake)

 p.s.
 I do this packaging as root - so I always need to
 # export  FORCE_UNSAFE_CONFIGURE=1

 Would be more friendly if this check could be reported earlier in
 ./configure rather than just before it finishes.

 On Fri, Jun 5, 2015 at 12:52 PM, Michael Felt mamf...@gmail.com wrote:

 FYI: AIX - not Solaris - but old-school UNIX in both cases.

 And, yes - it is /bin/sh - which is the 'Bourne shell behavior iirc,
 rather than ksh behavior, but the program is the default AIX (not solaris)
 ksh (see inode #)

   26 -r-xr-xr-x 15 bin  bin 1457 May 14  2012 hash
   58 -r-xr-sr-x  1 root security   37092 Apr 25  2014 chsh
  148 lrwxrwxrwx  1 root system28 Feb  6 13:50 fcinit.sh -
 /usr/sbin/rsct/bin/fcinit.sh
  149 lrwxrwxrwx  1 root system29 Feb  6 13:50 fcinit.csh -
 /usr/sbin/rsct/bin/fcinit.csh
  263 -r-xr-s---  1 root system  5884 Mar  7  2014 refresh
  331 -r-xr-xr-x  1 bin  bin  918 May 14  2012 recsh
  443 -r-xr-xr-x  1 bin  bin   185344 Mar  7  2014 csh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 Rsh
  460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 bsh
  540 -rwxr-xr-x  1 root system  4690 May  6  2013 c_rehash
  631 

Re: bug#20733: coreutils build problem

[Michael Felt]

FYI: AIX - not Solaris - but old-school UNIX in both cases.

And, yes - it is /bin/sh - which is the 'Bourne shell behavior iirc,
rather than ksh behavior, but the program is the default AIX (not solaris)
ksh (see inode #)

  26 -r-xr-xr-x 15 bin  bin 1457 May 14  2012 hash
  58 -r-xr-sr-x  1 root security   37092 Apr 25  2014 chsh
 148 lrwxrwxrwx  1 root system28 Feb  6 13:50 fcinit.sh -
/usr/sbin/rsct/bin/fcinit.sh
 149 lrwxrwxrwx  1 root system29 Feb  6 13:50 fcinit.csh -
/usr/sbin/rsct/bin/fcinit.csh
 263 -r-xr-s---  1 root system  5884 Mar  7  2014 refresh
 331 -r-xr-xr-x  1 bin  bin  918 May 14  2012 recsh
 443 -r-xr-xr-x  1 bin  bin   185344 Mar  7  2014 csh
 460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 Rsh
 460 -r-xr-xr-x  2 bin  bin  2900986 Aug 20  2014 bsh
 540 -rwxr-xr-x  1 root system  4690 May  6  2013 c_rehash
 631 lrwxrwxrwx  1 bin  bin   16 Dec 20 16:21 dsh -
/opt/csm/bin/dsh
 829 -r-xr-xr-x  1 bin  bin   287458 Mar 12  2013 msh
 845 lrwxrwxrwx  1 root system46 Dec 20 16:21 perfpmr.sh -
/data/prj/labserv/perf61-2014.04.30/perfpmr.sh
 907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 remsh
 907 -r-sr-xr-x  2 root system 28270 Mar  8  2014 rsh
 983 lrwxrwxrwx  1 root system17 Dec 20 16:21 tclsh -
/usr/bin/tclsh8.4
 986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 ksh
 986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 psh
 986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 rksh
 986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 sh
 986 -r-xr-xr-x  5 bin  bin   292316 Jun 30  2014 tsh
1031 lrwxrwxrwx  1 root system16 Dec 20 16:21 wish -
/usr/bin/wish8.4

AIX also supports ksh93 - but that is a different executable (different
inode)

michael@x071:[/usr/bin]ls -li *ksh*
986 -r-xr-xr-x 5 bin bin 292316 Jun 30  2014 ksh
932 -r-xr-xr-x 2 bin bin 902655 Jul 11  2014 ksh93
986 -r-xr-xr-x 5 bin bin 292316 Jun 30  2014 rksh
932 -r-xr-xr-x 2 bin bin 902655 Jul 11  2014 rksh93



On Fri, Jun 5, 2015 at 12:45 PM, Michael Felt mamf...@gmail.com wrote:

 My fear is that autoconf has introduced this catch-all as I have been
 running into it more frequently of late (first time was last November when
 I took my first attempt at packaging gcc.)

 I shall look at the patch and let you know - however, regardless of
 whether it works or not - is this something that autoconf is introducing,
 read changed - requiring you to make a patch. If so, while from autoconf
 perspective all may be well - it is not very user-friendly. (I just do not
 understand autoconf well enough to make that distinction).

 Thanks for looking! and listening!!

 On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake ebl...@redhat.com wrote:

 [adding autoconf]

 On 06/04/2015 01:17 PM, Paul Eggert wrote:
 
  On 06/04/2015 09:41 AM, Michael Felt wrote:
GEN  src/coreutils.h
  /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 

  Port to POSIX shell, which doesn't allow 'for i in ; do ...'.

 Actually, POSIX _does_ allow for missing words between 'in' and the
 terminator (; or newline) before 'do' (whether by a word that expands to
 nothing, or by omission of words), requiring that the body of the for
 statement is skipped in that case:


 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04

 But it is also true that older shells did not always follow this rule,
 so you are indeed better off always supplying at least one word that
 won't be expanded into nothingness.

 Hmmm, I thought that autoconf would document it as a portability
 pitfall, but I don't see it under 'for' in this link:


 https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

Re: bug#20733: coreutils build problem

[Michael Felt]

This is reassuring. Thank you for the reply.

On Fri, Jun 5, 2015 at 3:05 PM, Eric Blake ebl...@redhat.com wrote:

 On 06/05/2015 04:45 AM, Michael Felt wrote:

 [we tend to avoid top-posting on technical lists, as it makes it harder
 to follow the flow of the message]

  My fear is that autoconf has introduced this catch-all as I have been
  running into it more frequently of late (first time was last November
 when
  I took my first attempt at packaging gcc.)
 

 Paul's patch was specific to a coreutils file.  So far, I have not seen
 any evidence of autoconf introducing 'for x in ;' anywhere in configure.
  If you are seeing the same problem in multiple packages, so far it is
 because each package has made a similar mistake in their local
 configuration files.

  I shall look at the patch and let you know - however, regardless of
 whether
  it works or not - is this something that autoconf is introducing, read
  changed - requiring you to make a patch. If so, while from autoconf
  perspective all may be well - it is not very user-friendly. (I just do
 not
  understand autoconf well enough to make that distinction).

 If the syntax error is in autoconf.ac or in Makefile.am, then it is the
 package that wrote the file at fault.  If the syntax error is not in
 anything the package provides, but appears in the generated configure
 file, then it is more likely to be in automake or autoconf.

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

Re: bug#20733: coreutils build problem

[Paul Eggert]

Michael Felt wrote:

   GEN  src/coreutils.h
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.


This looks like the coreutils patch wasn't properly propagated somehow.  What's 
the output of 'make V=1'?

Re: bug#20733: coreutils build problem

[Michael Felt]

Better, but...

  GEN  lib/wctype.h
  GEN  src/coreutils.h
  GEN  src/version.c
  GEN  src/version.h
make  all-recursive
Making all in po
Target all is up to date.
Making all in .
  CC   lib/copy-acl.o
  CC   lib/set-acl.o
  CC   lib/acl-errno-valid.o
  CC   lib/acl-internal.o
  CC   lib/get-permissions.o
lib/get-permissions.c, line 258.5: 1506-045 (S) Undeclared identifier ret.
lib/get-permissions.c, line 260.20: 1506-280 (W) Function argument
assignment between types char* and const char* is not allowed.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 2.


Stop.


On Fri, Jun 5, 2015 at 4:24 PM, Paul Eggert egg...@cs.ucla.edu wrote:

 Michael Felt wrote:

 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
  rm -f src/coreutils.h
  for prog in ; do prog=`basenam


 Yes, it looks like something went wrong in your build process and you're
 using a Makefile.in generated from unpatched sources.  I just now built a
 distribution tarball from the bleeding edge sources, a tarball that
 shouldn't have this problem; can you give it a try?  It's here:

 http://www.cs.ucla.edu/~eggert/coreutils-8.23.209-7eaf8.tar.xz

Re: bug#20733: coreutils build problem

[Michael Felt]

I did not run config.status - this dog missed that part of the trick!

On Fri, Jun 5, 2015 at 4:30 PM, Eric Blake ebl...@redhat.com wrote:

 On 06/05/2015 08:09 AM, Michael Felt wrote:
  root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
  rm -f src/coreutils.h
  for prog in ; do prog=`basename

 That's missing the changes; are you sure you reran both 'automake' and
 'config.status' to regenerate your Makefile with the updated source?

 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

Re: bug#20733: coreutils build problem

[Michael Felt]

root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
rm -f src/coreutils.h
for prog in ; do prog=`basename
$prog`;  main=`echo $prog | tr '['
'_'`; echo SINGLE_BINARY_PROGRAM(\$prog\,
$main); done | sort  src/coreutils.ht
/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
make: 1254-004 The error code from the last command is 2.


Stop.
root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]


On Fri, Jun 5, 2015 at 4:07 PM, Paul Eggert egg...@cs.ucla.edu wrote:

 Michael Felt wrote:

GEN  src/coreutils.h
 /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
 make: 1254-004 The error code from the last command is 2.


 This looks like the coreutils patch wasn't properly propagated somehow.
 What's the output of 'make V=1'?

Re: bug#20733: coreutils build problem

[Paul Eggert]

Michael Felt wrote:

root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
 rm -f src/coreutils.h
 for prog in ; do prog=`basenam


Yes, it looks like something went wrong in your build process and you're using a 
Makefile.in generated from unpatched sources.  I just now built a distribution 
tarball from the bleeding edge sources, a tarball that shouldn't have this 
problem; can you give it a try?  It's here:


http://www.cs.ucla.edu/~eggert/coreutils-8.23.209-7eaf8.tar.xz

Re: bug#20733: coreutils build problem

[Eric Blake]

On 06/05/2015 08:09 AM, Michael Felt wrote:
 root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1
 rm -f src/coreutils.h
 for prog in ; do prog=`basename

That's missing the changes; are you sure you reran both 'automake' and
'config.status' to regenerate your Makefile with the updated source?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#20733: coreutils build problem

[Nick Bowler]

On 2015-06-04 14:41 -0600, Eric Blake wrote:
 On 06/04/2015 02:17 PM, Nick Bowler wrote:
  Do these problematic shells properly handle:
  
for arg
do
  ...
done
  
  when $# is 0?
 
 Yes; all shells do.

OK, good to know.

[...]
 it's not the expand-to-nothing that is a problem, it is the actual
 omission:
 
 $ /bin/sh -c 'for a in ; do :; done'
 /bin/sh: syntax error at line 1: `;' unexpected
 $ /bin/sh -c 'for a in $nothing; do :; done'
 $

Right, I see that now in the doc patch you posted.  So in Autoconf this
might turn up if you generate the list with m4, but is highly unlikely
to be an issue for pure shell code.

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: bug#20733: coreutils build problem

[Eric Blake]

On 06/04/2015 02:17 PM, Nick Bowler wrote:
 Do these problematic shells properly handle:
 
   for arg
   do
 ...
   done
 
 when $# is 0?

Yes; all shells do.

$ /bin/sh -c 'echo $#; for arg
do echo hi; done; echo bye'
0
bye

 
 If so, can we use the following as a workaround?
 
   set x words-that-might-expand-to-nothing; shift
   for arg
   do
 ...
   done

Not ideal, when there are shorter invocations that can do the same.  And
it's not the expand-to-nothing that is a problem, it is the actual omission:

$ /bin/sh -c 'for a in ; do :; done'
/bin/sh: syntax error at line 1: `;' unexpected
$ /bin/sh -c 'for a in $nothing; do :; done'
$

so anything that expands in shell to nothing (whether $nothing, ``, or
use of a shell variable rather than a make variable) is fine; the
problem is most common in Makefiles where make variables are expanded
before the shell sees anything.

 
 I suppose that might be hard to do in this /particular/ case, as it
 looks like the error is coming from a make rule.  The Autoconf manual
 quite emphatically says to avoid 'for arg; do ...' by using a newline
 instead of a semicolon, a feat which is not easily done in make rules.

The manual also has a workaround for getting a literal newline in make
rules:
 nlinit=`echo 'nl='; echo ''`; eval $$nlinit

although that only gives you $nl containing newline, and you'd still
need another layer of 'eval' if you wanted to actually write the
makefile fragment to interpret the newline as a separator between the
var-name and 'do'.  So yeah, it's not worth it.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#20733: coreutils build problem

[Paul Eggert]

Eric Blake wrote:

Actually, POSIX_does_  allow for missing words between 'in' and the
terminator (; or newline) before 'do' (whether by a word that expands to
nothing, or by omission of words), requiring that the body of the for
statement is skipped in that case:


Ah, sorry, I was thinking of previous versions of POSIX, which required at least 
one word after the 'in'.  You're right, the current POSIX version doesn't 
require this any more.  So the Solaris sh in question is conforming to the old 
POSIX standard but not to the current one.


I liked the approach with ``; I hadn't thought of that.  I used the coreutils 
fix I did because other coreutils code already fixed similar for-loop problems 
that way.

Re: bug#20733: coreutils build problem

[Nick Bowler]

On 2015-06-04 13:34 -0600, Eric Blake wrote:
 [adding autoconf]
 
 On 06/04/2015 01:17 PM, Paul Eggert wrote:
  
  On 06/04/2015 09:41 AM, Michael Felt wrote:
GEN  src/coreutils.h
  /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected.
  
 
  Port to POSIX shell, which doesn't allow 'for i in ; do ...'.
 
 Actually, POSIX _does_ allow for missing words between 'in' and the
 terminator (; or newline) before 'do' (whether by a word that expands to
 nothing, or by omission of words), requiring that the body of the for
 statement is skipped in that case:
 
 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04
 
 But it is also true that older shells did not always follow this rule,
 so you are indeed better off always supplying at least one word that
 won't be expanded into nothingness.
 
 Hmmm, I thought that autoconf would document it as a portability
 pitfall, but I don't see it under 'for' in this link:
 
 https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

Yikes!

Some questions:

Do these problematic shells properly handle:

  for arg
  do
...
  done

when $# is 0?

If so, can we use the following as a workaround?

  set x words-that-might-expand-to-nothing; shift
  for arg
  do
...
  done

I suppose that might be hard to do in this /particular/ case, as it
looks like the error is coming from a make rule.  The Autoconf manual
quite emphatically says to avoid 'for arg; do ...' by using a newline
instead of a semicolon, a feat which is not easily done in make rules.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Bug found

[Preston Travis Kennedy]

{app_name:MobileSafari,app_version:8.0,bundleID:com.apple.mobilesafari,adam_id:0,os_version:iPhone
 OS 8.3 
(12F70),slice_uuid:401d84e7-e929-354d-a4fb-270855328f6b,share_with_app_devs:true,build_version:600.1.4,is_first_party:true,bug_type:109,name:MobileSafari}
Incident Identifier: F6D2AA61-E996-40BE-B14C-C01F4C95F002
CrashReporter Key:   790d4d268993fadfb4cc6b32bb0d463a521ab505
Hardware Model:  iPhone7,1
Process: MobileSafari [296]
Path:/Applications/MobileSafari.app/MobileSafari
Identifier:  com.apple.mobilesafari
Version: 600.1.4 (8.0)
Code Type:   ARM-64 (Native)
Parent Process:  launchd [1]

Date/Time:   2015-05-06 23:09:32.760 -0500
Launch Time: 2015-05-06 20:55:39.167 -0500
OS Version:  iOS 8.3 (12F70)
Report Version:  105

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0010
Triggered by Thread:  4

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib  0x0001954d4e0c 0x1954d4000 + 3596
1   libsystem_kernel.dylib  0x0001954d4c84 0x1954d4000 + 3204
2   CoreFoundation  0x0001834e3720 0x183404000 + 915232
3   CoreFoundation  0x0001834e1674 0x183404000 + 906868
4   CoreFoundation  0x00018340d2d0 0x183404000 + 37584
5   GraphicsServices0x00018cc236f8 0x18cc18000 + 46840
6   UIKit   0x000187fd2fa8 0x187f5c000 + 487336
7   MobileSafari0x0001000b2d24 0x1000ac000 + 27940
8   libdyld.dylib   0x0001953d6a04 0x1953d4000 + 10756

Thread 1 name:  Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0   libsystem_kernel.dylib  0x0001954d4c24 0x1954d4000 + 3108
1   libdispatch.dylib   0x0001953b9e6c 0x1953a8000 + 73324
2   libdispatch.dylib   0x0001953ab998 0x1953a8000 + 14744

Thread 2 name:  com.apple.NSURLConnectionLoader
Thread 2:
0   libsystem_kernel.dylib  0x0001954d4e0c 0x1954d4000 + 3596
1   libsystem_kernel.dylib  0x0001954d4c84 0x1954d4000 + 3204
2   CoreFoundation  0x0001834e3720 0x183404000 + 915232
3   CoreFoundation  0x0001834e1674 0x183404000 + 906868
4   CoreFoundation  0x00018340d2d0 0x183404000 + 37584
5   CFNetwork   0x000182eee890 0x182e5 + 649360
6   Foundation  0x00018442ddb4 0x184338000 + 1007028
7   libsystem_pthread.dylib 0x00019558bdc4 0x195588000 + 15812
8   libsystem_pthread.dylib 0x00019558bd20 0x195588000 + 15648
9   libsystem_pthread.dylib 0x000195588ef4 0x195588000 + 3828

Thread 3:
0   libsystem_kernel.dylib  0x0001954d4e0c 0x1954d4000 + 3596
1   libsystem_kernel.dylib  0x0001954d4c84 0x1954d4000 + 3204
2   CoreFoundation  0x0001834e3720 0x183404000 + 915232
3   CoreFoundation  0x0001834e1674 0x183404000 + 906868
4   CoreFoundation  0x00018340d2d0 0x183404000 + 37584
5   CoreFoundation  0x00018345f358 0x183404000 + 373592
6   CoreMotion  0x000183e18364 0x183dd + 295780
7   libsystem_pthread.dylib 0x00019558bdc4 0x195588000 + 15812
8   libsystem_pthread.dylib 0x00019558bd20 0x195588000 + 15648
9   libsystem_pthread.dylib 0x000195588ef4 0x195588000 + 3828

Thread 4 name:  WebThread
Thread 4 Crashed:
0   libobjc.A.dylib 0x000194d6bbd0 0x194d5 + 113616
1   UIKit   0x000187fa24bc 0x187f5c000 + 287932
2   MediaPlayer 0x0001858317c0 0x1857cc000 + 415680
3   MediaPlayer 0x000185830138 0x1857cc000 + 409912
4   UIKit   0x000187f6975c 0x187f5c000 + 55132
5   QuartzCore  0x0001878b1e18 0x1878a4000 + 56856
6   QuartzCore  0x0001878ac880 0x1878a4000 + 34944
7   UIKit   0x000187f7df90 0x187f5c000 + 139152
8   UIKit   0x000187f8382c 0x187f5c000 + 161836
9   MediaPlayer 0x000185830928 0x1857cc000 + 411944
10  MediaPlayer 0x0001858a39fc 0x1857cc000 + 883196
11  MediaPlayer 0x000185830280 0x1857cc000 + 410240
12  UIKit   0x000187f682b8 0x187f5c000 + 49848
13  UIKit   0x000187f740ac 0x187f5c000 + 98476
14  MediaPlayer 0x000185833524 0x1857cc000 + 423204
15  MediaPlayer 

Re: Bug found

[Eric Blake]

On 05/06/2015 10:34 PM, Preston Travis Kennedy wrote:
 
 {app_name:MobileSafari,app_version:8.0,bundleID:com.apple.mobilesafari,adam_id:0,os_version:iPhone
  OS 8.3 
 (12F70),slice_uuid:401d84e7-e929-354d-a4fb-270855328f6b,share_with_app_devs:true,build_version:600.1.4,is_first_party:true,bug_type:109,name:MobileSafari}
 Incident Identifier: F6D2AA61-E996-40BE-B14C-C01F4C95F002

Thanks for the report; however, I fail to see how this is relevant to
autoconf.  It looks like this is a bug that should be reported to
MobileSafari folks.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))

[Gary V. Vaughan]

[[Adding Autoconf List, the home of autoreconf]]

On Jan 16, 2015, at 1:26 PM, Gary V. Vaughan g...@vaughan.pe wrote:
 And the problem is that autoreconf, as called from the
 autogen.sh in the tarball, still runs the tools in the wrong order.
 Autoreconf stupidly runs aclocal first, and then calls libtoolize which
 adds more m4 files to AC_CONFIG_MACRO_DIR, and that in turn causes
 aclocal.m4 to be out of date (because it needs to be regenerated to pick
 up the local versions of the libtoolize added m4 files added to
 ../config/ after it was first generated).
 
 actually, (at least modern enough) autoreconf runs the aclocal twice.
 Once before libtoolize call (do detect whether it should call the
 libtoolize tool at all) and second time [1] after libtoolize to
 incorporate the macros.
 
 That's good to know.  I stopped closely following autoconf development a
 few years ago, and didn't realise this was finally cleaned up.  Some of
 these corner case may be because of my slightly out of date view of how
 these tools interact :-(

Now that I think about it, why is it necessary to run aclocal just to
find out whether LT_INIT, AM_PROG_LIBTOOL or AC_PROG_LIBTOOL is invoked?
I know that for a full m4 --trace run, one needs to have some (possibly
outdated) versions of required macros available, but it's very easy to
work around that: see the implementation of `func_require_libtoolize` in
the libtool bootstrap script (my clean rewrite of the gnulib bootstrap
script).

Further, now that autoconf is actively maintained again, why do we have
a vestigial autoreconf and a whole zoo of autogen.sh and bootstrap scripts?
Wouldn't it make more sense to centralize and maintain all of this in the
one true autoreconf?  Merging my bootstrap script with the latest autoreconf
eliminates the spurious rerun of aclocal, and brings support for gettext,
gnulib and per-project customizations.

It doesn't seem like a great deal of work to translate 700 lines of perl
into shell, fold it into bootstrap, and ship the result as autoreconf in the
next release of Autoconf.  Then everyone can go back to running `autoreconf
-fvi` and be done with the whole mess of wrapper scripts...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

BUG of unfindable (and likely un-necessary) PRE-REQUIREMENT

[John D. Hendrickson]

GNU M4 is a prerequisite for Autoconf.

  but m4 has been altered to require make and also autoconf
  not to mention perl, also other things; before they handn't been

http://www.perl.org/

  but perl requires autoconf and m4 and other things

  perl is taken from awk and so much better i understand
  but i'm unsure why autoconf, make, and gcc now depend on it
  because in the past they didn't

i am researching what the build path of as(1) - gcc(1) - X11R7.6 just 
for pc nothing complicated


what i'm finding is many dependancy issues that keep changing even 
during the process and ...


   ie, i'm on filewatcher.org looking for scattered sources

but my quest is to have a VERSION that distro admins didn't release; a 
backport of X11 using new but trim kernel and older unix base.  it works 
it's firefox GTK that throws a flag.


GTK (or was it gdk?)  demanded i upgrade gcc , and here i am

i'm ending up with more task than i'd hoped for and little help

i know how bit it's a been made a terrible process.

i can barely find and make a (chroot) which can upstart from scratch 
which does not end up REQUIRING ITSELF IN THE RESULT by depends


see ? :)

thanks wonderful too have a good day and all that  -jh

Re: BUG of unfindable (and likely un-necessary) PRE-REQUIREMENT

[Eric Blake]

On 12/10/2014 11:22 AM, John D. Hendrickson wrote:
 
 GNU M4 is a prerequisite for Autoconf.

Correct.  Installed GNU M4 is a prerequiste for using autoconf.

 
   but m4 has been altered to require make and also autoconf

Correct - but ONLY for building from m4.git.  It is NOT a requirement to
have autoconf installed in order to build m4 from a tarball.  In other
words, there is no circular dependency.  Grab an m4 tarball, build and
install that.  Then grab an autoconf tarball, build and install that.
From there, you can now grab m4.git and autoconf.git if you want
latest-and-greatest unreleased versions, or stick with the tarball
builds that you already installed.

 
 i can barely find and make a (chroot) which can upstart from scratch
 which does not end up REQUIRING ITSELF IN THE RESULT by depends
 
 see ? :)

You're not the first person to ask about this; nor will you be the last.
 But so far, you haven't raised any actual bug reports, but merely
repeated what is already known.

 
 thanks wonderful too have a good day and all that  -jh

Sarcasm doesn't work well in email.  I don't know whether you are trying
to vent frustration, or offer on advice on something that we need to
change (better documentation about bootstrapping), or something else
entirely.  At any rate, I wish you luck on getting your desired software
installed.  You can always use a pre-built distribution to save yourself
the headaches of figuring it out for yourself.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#18916: libtool-2.4.3 caused autoconf test failure

[Gary V. Vaughan]

On Oct 31, 2014, at 10:11 PM, Eric Blake ebl...@redhat.com wrote:
 
 [adding libtool]
 
 On 10/31/2014 10:54 AM, Bruce Dubbs wrote:
 From the test output:
 
 Compatibility with other tools.
 
 501: Libtool  FAILED (foreign.at:61)
 --
 This was caused by libtool-2.4.3.  Using the identical instructions when
 libtool-2.4.2 is used, the test passes.
 
 Thanks for the report.  Yes, autoconf should be taught to be more
 tolerant of new libtool, but this is probably also worth investigating
 if it is a libtool regression worth fixing for the upcoming 2.4.4.

The failure is because latest libtool (and libtoolize et. al) are following
the rest of GNU in eschewing `backtick opening quotes' in favour of 'regular
single quotes at both ends' style.

The sed expression in foreign.at at line 60 should accept either format to
be compatible with new and old libtoolize output.  E.g.:

  AT_CHECK([sed -n [s,^[^']*[\`']\\(/[^']*\\)'.*,\\1,p] stdout], [0], 
[stdout])

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: bug#18916: libtool-2.4.3 caused autoconf test failure

[Eric Blake]

On 11/02/2014 07:51 PM, Gary V. Vaughan wrote:

 501: Libtool  FAILED (foreign.at:61)

 
 The failure is because latest libtool (and libtoolize et. al) are following
 the rest of GNU in eschewing `backtick opening quotes' in favour of 'regular
 single quotes at both ends' style.

Thanks for the analysis.

 
 The sed expression in foreign.at at line 60 should accept either format to
 be compatible with new and old libtoolize output.  E.g.:
 
   AT_CHECK([sed -n [s,^[^']*[\`']\\(/[^']*\\)'.*,\\1,p] stdout], [0], 
 [stdout])

Obvious patch pushed to autoconf.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Eric Blake]

On 05/11/2014 02:48 PM, Paul Eggert wrote:
 Following up to the grep snapshot announcement in:
 
 http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html
 
 That snapshot failed to build the shell scripts egrep and fgrep properly
 on Solaris 10, because it set SHELL = /bin/sh in src/Makefile, which
 caused the makefile to put #!/bin/sh at the top of the shell scripts,
 which breaks because the shell scripts use a construct '${0%/*}' that
 Solaris 10 /bin/sh doesn't grok.  The build should have used SHELL =
 /bin/bash, which is what grep does with my test builds.

In autoconf.git, there are zero hits for:
git grep -F '0%/*'

However, in grep.git, there is:

src/egrep.sh:if test -x ${0%/*}/@grep@; then
src/egrep.sh:  PATH=${0%/*}:$PATH

The culprit is grep itself, not autoconf.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Jim Meyering]

On Sun, May 11, 2014 at 1:48 PM, Paul Eggert egg...@cs.ucla.edu wrote:
 Following up to the grep snapshot announcement in:

 http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html

 That snapshot failed to build the shell scripts egrep and fgrep properly on
 Solaris 10, because it set SHELL = /bin/sh in src/Makefile, which caused
 the makefile to put #!/bin/sh at the top of the shell scripts, which
 breaks because the shell scripts use a construct '${0%/*}' that Solaris 10
 /bin/sh doesn't grok.  The build should have used SHELL = /bin/bash, which
 is what grep does with my test builds.

 We could work around the problem by avoiding that shell construct, but I'd
 rather fix the build machinery because this bug could affect any package
 that uses POSIX shell scripts.  The snapshot was built with an experimental
 version of Autoconf (2.69.117-1717), whereas I had tested with the latest
 stable version (2.69 as shipped with Fedora 20).  The two versions differ in
 how they compute the name of a working shell, so it appears that there's a
 bug in the experimental version of Autoconf.

 A quick workaround for grep is to build the next snapshot with Autoconf
 2.69.  In the long run, though, we should fix the Autoconf bug.  I'll CC:
 this to bug-autoconf to give them a heads-up.

Hi Paul,
Thanks for reporting that.
I would like our egrep and fgrep scripts to work even on systems with
a non-POSIX shell and no bash to fall back on. Our tests/init.sh
code tries hard to find a sufficiently functional shell (including a
test for the ${VAR%GLOB} construct), and making it work in spite of
Solaris's /bin/sh was tricky, and we had to be willing to give up and
skip tests altogether, in the event that no sufficiently featureful
shell is found.  Here, we don't have that luxury.

Ideally, these wrapper shell scripts would not have to fork an extra
process to perform this trivial string manipulation, but I can live
with the extra overhead, expecially for scripts like these that merely
provide support for obsolescent-named programs.

I think the attach patch is sufficiently portable to do what I want.
Does anyone see a way to make it more efficient with a POSIX shell?


0001-egrep-fgrep-make-wrappers-portable-to-non-POSIX-shel.patch
Description: Binary data

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Jim Meyering]

On Sun, May 11, 2014 at 1:48 PM, Paul Eggert egg...@cs.ucla.edu wrote:
 Following up to the grep snapshot announcement in:

 http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html

 That snapshot failed to build the shell scripts egrep and fgrep properly on
 Solaris 10, because it set SHELL = /bin/sh in src/Makefile, which caused
 the makefile to put #!/bin/sh at the top of the shell scripts, which
 breaks because the shell scripts use a construct '${0%/*}' that Solaris 10
 /bin/sh doesn't grok.  The build should have used SHELL = /bin/bash, which
 is what grep does with my test builds.

 We could work around the problem by avoiding that shell construct, but I'd
 rather fix the build machinery because this bug could affect any package
 that uses POSIX shell scripts.  The snapshot was built with an experimental
 version of Autoconf (2.69.117-1717), whereas I had tested with the latest
 stable version (2.69 as shipped with Fedora 20).  The two versions differ in
 how they compute the name of a working shell, so it appears that there's a
 bug in the experimental version of Autoconf.

 A quick workaround for grep is to build the next snapshot with Autoconf
 2.69.  In the long run, though, we should fix the Autoconf bug.  I'll CC:
 this to bug-autoconf to give them a heads-up.

Hi Paul,
Thanks for reporting that.
I would like our egrep and fgrep scripts to work even on systems with
an old shell and no bash to fall back on. Our tests/init.sh code
tries hard to find a sufficiently functional shell (including a test
for the ${VAR%GLOB} construct), and making it work in spite of
Solaris's /bin/sh was tricky... plus, we had to be willing to give up
and skip tests altogether, in the event that no sufficiently
functional shell is found.  Here, we don't have that luxury.

Ideally, these wrapper shell scripts would not have to fork an extra
process to perform this trivial string manipulation, but I can live
with the extra overhead, especially for scripts like these that merely
provide support for obsolescent programs.

I think the attached patch is sufficiently portable to work everywhere.
Does anyone see a (simple+clean) way to make it more efficient for the
common case in which @SHELL@ is a more functional shell?

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Nick Bowler]

On 2014-05-12 10:33 -0700, Jim Meyering wrote:
[...]
 I think the attach patch is sufficiently portable to do what I want.
 Does anyone see a way to make it more efficient with a POSIX shell?

 From e2a305bff2be376f6dd29e52a1d32636e0c22706 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@fb.com
 Date: Mon, 12 May 2014 10:33:09 -0700
 Subject: [PATCH] egrep, fgrep: make wrappers portable to non-POSIX shells
 
 * src/egrep.sh (grep): Use sed in a subshell in place of the
 POSIX sh construct, ${0%/*}.  The latter is not portable to
 Solaris 10.  Reported by Paul Eggert in http://debbugs.gnu.org/17471
 ---
  src/egrep.sh | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/src/egrep.sh b/src/egrep.sh
 index f1b4146..0a374aa 100644
 --- a/src/egrep.sh
 +++ b/src/egrep.sh
 @@ -2,9 +2,10 @@
  grep=grep
  case $0 in
*/*)
 -if test -x ${0%/*}/@grep@; then
 -  PATH=${0%/*}:$PATH
 -  grep=@grep@
 +dirname=`echo $0|sed 's,//*[^/]*$,,'`

I'd write

   dirname=`expr x$0 : x'\(.*\)/'`

but mainly for style reasons...

 +if test -x $dirname/'@grep@'; then
 +  PATH=$dirname:$PATH
 +  grep='@grep@'
  fi;;
  esac
  exec $grep @option@ $@

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Paul Eggert]

On 05/12/2014 10:33 AM, Jim Meyering wrote:

Does anyone see a way to make it more efficient with a POSIX shell?


Yes. Eric's earlier message convinced me that grep shouldn't rely on 
Autoconf guaranteeing a shell that supports substrings in parameter 
expansion, so I came up with the attached patch (which keeps the shell 
efficient with a POSIX shell) and pushed it before I got around to 
reading your message.  I tested on Solaris 10 with the shell 
artificially set to /bin/sh, so I'm marking this as done.


From an Autoconf point of view it might be nice to have a good way to 
say I need a POSIX shell or at least I need a shell that does 
substrings, but that's merely a wishlist item.
From 0ca1f6d79514189ef8db6e931f285cbaec9789ec Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Mon, 12 May 2014 11:38:28 -0700
Subject: [PATCH] egrep, fgrep: port to Solaris 10 /bin/sh

This old shell doesn't grok ${0%/*}; see: http://bugs.gnu.org/17471
* src/Makefile.am (egrep fgrep): Don't assume the shell does substrings.
* src/egrep.sh (dir): New var, so that the substring calculation is
done only once (which is a small win even with newer shells),
and so that the calculation is easier to edit on older shells.
---
 src/Makefile.am | 7 +++
 src/egrep.sh| 5 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index f8c9415..e2c82a4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -47,7 +47,14 @@ EXTRA_DIST = dosbuf.c egrep.sh
 egrep fgrep: egrep.sh Makefile
 	$(AM_V_GEN)grep=`echo grep | sed -e '$(transform)'`	 \
 	case $@ in egrep) option=-E;; fgrep) option=-F;; esac	 \
+	shell_does_substrings='set x/y  d=$${1%/*}  test $$d = x'  \
+	if $(SHELL) -c $$shell_does_substrings 2/dev/null; then \
+	  edit_substring='s,X,X,'; \
+	else \
+	  edit_substring='s,\$${0%/\*},`expr X$$0 : '\''X\\(.*\\)/'\''`,g'; \
+	fi  \
 	sed -e 's|[@]SHELL@|$(SHELL)|g' \
+	-e $$edit_substring \
 	-e s|[@]grep@|$$grep|g \
 	-e s|[@]option@|$$option|g $(srcdir)/egrep.sh $@-t
 	$(AM_V_at)chmod +x $@-t
diff --git a/src/egrep.sh b/src/egrep.sh
index f1b4146..1a03d2a 100644
--- a/src/egrep.sh
+++ b/src/egrep.sh
@@ -2,8 +2,9 @@
 grep=grep
 case $0 in
   */*)
-if test -x ${0%/*}/@grep@; then
-  PATH=${0%/*}:$PATH
+dir=${0%/*}
+if test -x $dir/@grep@; then
+  PATH=$dir:$PATH
   grep=@grep@
 fi;;
 esac
-- 
1.9.0

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Jim Meyering]

Thanks for dealing with that.
The only potential problem I see with your patch would be when
one runs configure with a perverse program name transformation,
e.g., --program-transform-name='s/^/$/', introducing a shell
metacharacter (or leading/trailing white space!) in the resulting
name.  In that case, the lack of single quotes around @grep@
would be fatal.

Fixing that is not high priority. Anyone who does that to
grep deserves the result :-)

On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

[Paul Eggert]

Following up to the grep snapshot announcement in:

http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html

That snapshot failed to build the shell scripts egrep and fgrep properly 
on Solaris 10, because it set SHELL = /bin/sh in src/Makefile, which 
caused the makefile to put #!/bin/sh at the top of the shell scripts, 
which breaks because the shell scripts use a construct '${0%/*}' that 
Solaris 10 /bin/sh doesn't grok.  The build should have used SHELL = 
/bin/bash, which is what grep does with my test builds.


We could work around the problem by avoiding that shell construct, but 
I'd rather fix the build machinery because this bug could affect any 
package that uses POSIX shell scripts.  The snapshot was built with an 
experimental version of Autoconf (2.69.117-1717), whereas I had tested 
with the latest stable version (2.69 as shipped with Fedora 20).  The 
two versions differ in how they compute the name of a working shell, so 
it appears that there's a bug in the experimental version of Autoconf.


A quick workaround for grep is to build the next snapshot with Autoconf 
2.69.  In the long run, though, we should fix the Autoconf bug.  I'll 
CC: this to bug-autoconf to give them a heads-up.

Re: [Bug-tar] testsuite.log too large for mailing lists

[Pavel Raiskup]

On Wednesday, January 08, 2014 23:52:47 Karl Berry wrote:
 Hi Sergey/all - when make check fails, it advises the user to email
 testsuite.log to bug-tar.  That is nice in theory, but the log is big
 these days, and there are a lot of people on bug-tar, ie, we're talking
 a lot of bandwidth to distribute such a message.
 
 I suggest changing the msg to say to compress the log first.  I expect
 that would reduce the size greatly.

 (Or is this an automake issue?  Probably.  But I'll write here first
 anwyay.  I admit I'm sending this blind after user feedback, I don't
 have a failing test at hand myself.  Some quick greps in the source did
 not clarify.)

This seems to be autoconf RFE, added to CC.  Following simple change could
help; but as not all projects may agree (some automatic report parsers?),
it could be useful to have a way how to configure that message.

| diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
| index 06d7546..2942ca0 100644
| --- a/lib/autotest/general.m4
| +++ b/lib/autotest/general.m4
| @@ -1642,7 +1642,7 @@ else
|else
|  at_msg=\`${at_testdir+${at_testdir}/}$as_me.log'
|fi
| -  AS_ECHO([Please send $at_msg and all information you think might help:
| +  AS_ECHO([Please send compressed $at_msg and all information you think 
might help:
|  
| To: AT_PACKAGE_BUGREPORT
| Subject: @:@AT_PACKAGE_STRING@:@ $as_me: dnl

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Eric Blake]

On 01/19/2013 06:10 AM, Stefano Lattarini wrote:
 [-cc automake-patches]
 
 On 01/16/2013 06:48 PM, Paul Eggert wrote:
 On 01/16/13 04:46, Stefano Lattarini wrote:
 Makes sense.  Should I try to implement something along these lines (might
 take a few days), or are you planning to do that yourself (in which case
 I'll avoid the duplicated efforts)?

 I wasn't planning on doing that, so please go ahead.

 Here is my attempt.  OK to go in Autoconf 2.70?

Close, but I have some ideas for improvements.

 
 +- AC_PROG_CC_C_O implements saner semantics if the new witness macro
 +  AC_PROG_CC_C_O_USE_MODERN_SEMANTICS is defined (see the documentation
 +  for details).  Future versions of autoconf might make such new
 +  semantics the default at some point.

Thnking about a forward-compatibility issue - what happens if, when we
switch semantics, someone still needs to get back to the old semantics?
 Do we add yet another witness macro at that time?  And how does such a
package work with both old and new autoconf at once?

Rather, a better plan is to make AC_PROG_CC_C_O be configurable via a
single witness, by taking an optional argument that determines _which_
semantics to use and having the witness be a non-empty string to alter
defaults.  All existing versions of autoconf ignore macro arguments to
AC_PROG_CC_C_O, so we can add an optional argument, and document it as
follows:

===
AC_PROG_CC_C_O([mode])
--
If MODE is given with the value 'sane', use the new semantics (for 2.70
and beyond). If MODE is given with the value 'old' (or for 2.69 and
earlier), use the backwards-compatible semantics.  If MODE is omitted,
which of the two semantics will default to the value of the macro
AC_PROG_CC_C_O_MODE (for 2.70 and beyond).

AC_PROG_CC_C_O_MODE
---
This macro is predefined in autoconf 2.70 to have the value 'old'; but
packages may redefine it to contain 'sane' to impact how AC_PROG_CC_C_O
will behave if called without arguments.  A future version of autoconf
may switch this macro to have the value 'sane'.
==

Usage wise, a configure.ac that uses AC_PROG_CC_C_O([old]) will always
have old semantics, regardless of which autoconf version it is built
with.  A configure.ac that uses AC_PROG_CC_C_O without arguments (most
existing scripts) will default to old semantics under older automake;
but Automake 1.14 can do 'm4_define([AC_PROG_CC_C_O_MODE], [sane])' at
initialization time, to take advantage of sane semantics.

Implementation-wise, it would look something like this in autoconf 2.70
(rough draft):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_if(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [new semantics])])

or, if we wanted to reject invalid input (rather than silently treating
all strings != 'old' as 'sane'):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_case(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [sane], [new semantics],
  [m4_fatal([unrecognized mode: $1])])])

Either way, you need only switch one line in a future autoconf to
default to new semantics.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Stefano Lattarini]

On 01/15/2013 04:16 AM, Paul Eggert wrote:
 On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
  or 'clang') supports -c -o together.  Why?  If the user has a
  broken base vendor compiler, but has installed a better one (say
  GCC), why should he still be penalized?
 
 I don't know.  It's been that way for two decades or so, for no
 reason that I can see.
  
   2. The fact the cache variable used by the test is based on the
  contents of the $CC expansion seems fragile and confusing.  AFICS,
  none of the other cache variables referring to check on the
  selected C compiler has this property -- so why should this one?
 
 Again, no good reason that I can see.
 
 So, my question is: could any of this semantics be improved in the
 obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
 macro for backward-compatibility considerations (and risking to introduce
 incompatibilities a last minute change might indeed not be a good idea),
 
 We could have the change take effect only if some other macro is invoked,
 indicating that the user wants the new behavior.  That should be safe.
 The default behavior can be the old behavior for now, with the intent that
 this will eventually change to the new behavior.
 
Makes sense.  Should I try to implement something along these lines (might
take a few days), or are you planning to do that yourself (in which case
I'll avoid the duplicated efforts)?

Thanks,
  Stefano

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/16/13 04:46, Stefano Lattarini wrote:
 Makes sense.  Should I try to implement something along these lines (might
 take a few days), or are you planning to do that yourself (in which case
 I'll avoid the duplicated efforts)?

I wasn't planning on doing that, so please go ahead.

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Eric Blake]

On 01/16/2013 10:48 AM, Paul Eggert wrote:
 On 01/16/13 04:46, Stefano Lattarini wrote:
 Makes sense.  Should I try to implement something along these lines (might
 take a few days), or are you planning to do that yourself (in which case
 I'll avoid the duplicated efforts)?
 
 I wasn't planning on doing that, so please go ahead.

Didn't you already add _AM_PROG_CC_C_O_HELPME; is that a sufficient
witness macro for whether to use the proposed cleanups?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?

[Eric Blake]

[adding bug-autoconf, as owner of the source that becomes the generic
GNU INSTALL file]

On 01/03/2013 01:33 PM, Bob Friesenhahn wrote:
 On Thu, 3 Jan 2013, Stefano Lattarini wrote:

 It is a problem that MAKE is not mentioned in the standard
 GNU INSTALL file, or in Automake's own INSTALL file.

 The latter is not surprising, since Automake's INSTALL file is
 merely a copy of the generic GNU one.

 If this variable was never mentioned by any instructional text,
 users can't be expected to ever use it.

 This makes sense?  Care to attempt a patch?  I'm not going to
 do it myself, I must admit.
 
 If Automake-dependent packages are dependent on MAKE, then it seems that
 mention of MAKE should be added to the standard GNU INSTALL file (not
 just Automake's copy).
 
 Previous to use by Automake in configure scripts, MAKE was an
 environment variable used for internal communication from a parent make
 process to a subordinate make process and set by make itself.

So what's the verdict - do we (want to) support the user overriding
MAKE, and therefore document that in INSTALL?  For that matter, should
autoconf (and/or automake) mark MAKE as a precious variable, so that it
gets listed in './configure --help', and so 'MAKE=gmake ./configure' has
the same results as './configure MAKE=gmake'?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature