Ralf Wildenhues | 2 Jan 20:29 2008
Picon
Picon

test-memmem takes waaay too long

Hello, and a Happy New Year,

quoting memmem.m4:

    AC_CACHE_CHECK([whether memmem works], [gl_cv_func_memmem_works],
      [AC_RUN_IFELSE([AC_LANG_PROGRAM([#include <string.h>],
          [return !memmem ("a", 1, NULL, 0);])],
        [gl_cv_func_memmem_works=yes], [gl_cv_func_memmem_works=no],
        [dnl pessimistically assume the worst, since even glibc 2.6.1
         dnl has quadratic complexity in its memmem
         gl_cv_func_memmem_works=no])])

This sets gl_cv_func_memmem_works=yes in the non-cross-compiling case,
tested on GNU/Linux with glibc 2.3.6, which in turn causes the
test-memmem.c test to take an awful lot of time to complete (I killed
it after several minutes).  I noticed this with git master M4.

I suggest that either the testsuite test use some time limit (alarm?),
or the configure test tries to expose the quadratic complexity, or the
configure test assume `no' on systems where we know libc's memmem to be
insufficient.

Cheers,
Ralf

R. Clayton | 12 Jan 20:08 2008
Picon

$# handles zero arguments incorrectly.

  $ m4 --version
  m4 (GNU M4) 1.4.10
  Copyright (C) 2007 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.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 Rene' Seindal.

  $ cat bad
  define(`nargs', `$#')
  nargs()
  nargs(1)
  nargs(1, 2)

  $ m4 < bad

  1
  1
  2

  $ 

This is on a debian testing system updated weekly.

  $ uname -a
  Linux UlanBator 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux

  $
(Continue reading)

Eric Blake | 13 Jan 00:54 2008
Picon

Re: $# handles zero arguments incorrectly.


According to R. Clayton on 1/12/2008 12:08 PM:
|   $ m4 --version
|   m4 (GNU M4) 1.4.10
|   $ cat bad
|   define(`nargs', `$#')
|   nargs()

Not a bug.  You were invoking nargs with one argument, the empty string.
To invoke a macro without arguments, you must omit the ().  The manual
should make this clear:
http://www.gnu.org/software/m4/manual/html_node/Pseudo-Arguments.html#Pseudo-Arguments

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

Eric Blake             ebb9 <at> byu.net
R. Clayton | 13 Jan 02:45 2008
Picon

Re: $# handles zero arguments incorrectly.

Not a bug.  You were invoking nargs with one argument, the empty string.  To
invoke a macro without arguments, you must omit the ().

  Ah; my apologies.

The manual should make this clear:

  It tried, but I chose to see what I wanted to, rather than what was there.

  Thanks for your reply.
Chan, Lawson | 30 Jan 20:46 2008

RE: GNU M4

 Hi Eric,

Thanks for your reply.  I am sorry that I have difficulties in removing the disclaimer because it is out of my
control.  I am running the make in both shell (bash or Korn) and they have exactly the same behaviour.

/M4/m4-1.4.10/checks
 bash: fail: unbound variable
 *** Error code 1
 make:  Fatal error: Command failed for target 'all-recursive'

Here is the attached configure and make output file for your reference.

Yes, the ./configure is successfully executed.  Any thought about this?

Thanks,

Lawson

-----Original Message-----
From: Eric Blake [mailto:ebb9 <at> byu.net]
Sent: Wednesday, January 30, 2008 2:27 PM
To: Chan, Lawson
Cc: gary <at> gnu.org
Subject: Re: GNU M4

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

Please post to the list (bug-m4 <at> gnu.org) instead of individual developers, so that others may chime in or
benefit from the conversation, and so that you are less likely to catch a developer on vacation.  And when
(Continue reading)

Eric Blake | 30 Jan 21:06 2008
Picon

'set -u' and $SHELL in makefiles [was: GNU M4]


[adding bug-automake; this is
http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2388]

According to Chan, Lawson on 1/30/2008 12:46 PM:
|  Hi Eric,
|
| Thanks for your reply.  I am sorry that I have difficulties in removing
the disclaimer because it is out of my control.

Nothing prevents you from using a free webmail account, or finding a
newsreader gateway that won't add a disclaimer (I personally like gmane).

|  I am running the make in both shell (bash or Korn) and they have
exactly the same behaviour.

It doesn't matter what shell you ran make from; what mattered is what
shell make was running as it spawned commands.  What does 'env | grep
SHELL' say?  Your log shows that you are running bash 2.03, which is
rather old, but I don't think that's an issue.  I personally know that M4
builds just fine on Solaris 8, so it is something about your environment
that caused your failure, and not a flaw in the M4 package.

|
| /M4/m4-1.4.10/checks
|  bash: fail: unbound variable
|  *** Error code 1
|  make:  Fatal error: Command failed for target 'all-recursive'
|
| Here is the attached configure and make output file for your reference.
(Continue reading)

Chan, Lawson | 30 Jan 21:19 2008

RE: 'set -u' and $SHELL in makefiles [was: GNU M4]

Hi Eric,

1)  I am sorry that I couldn't use a free webmail account at work.
2)  Running the 'env | grep SHELL' gives SHELL=/usr/bin/ksh
3)  I use the following commands to start the execution
    ./configure
    make
4)  I tried to use the command " set +u" to disable the u option before running the ./configure and it gives me
exactly the same result.
5)  I tried using make -k to build M4 and it gives me the same error.

Do you know where should I investigate on this issue?

Thanks,

Lawson

-----Original Message-----
From: Eric Blake [mailto:ebb9 <at> byu.net]
Sent: Wednesday, January 30, 2008 3:07 PM
To: Chan, Lawson
Cc: bug-m4 <at> gnu.org; gary <at> gnu.org; bug-automake <at> gnu.org
Subject: 'set -u' and $SHELL in makefiles [was: GNU M4]

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

[adding bug-automake; this is
http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2388]

(Continue reading)

Eric Blake | 30 Jan 22:23 2008
Picon

Re: 'set -u' and $SHELL in makefiles [was: GNU M4]


According to Chan, Lawson on 1/30/2008 1:19 PM:
| Hi Eric,
|
| 1)  I am sorry that I couldn't use a free webmail account at work.
| 2)  Running the 'env | grep SHELL' gives SHELL=/usr/bin/ksh

So your default shell is ksh, but the error message seen during make was
coming from bash, so something else is going on here.  We need to figure
out how SHELL is getting changed when used by the Makefile.

| 3)  I use the following commands to start the execution
|     ./configure
|     make

OK - seems simple enough.

| 4)  I tried to use the command " set +u" to disable the u option before
running the ./configure and it gives me exactly the same result.

Do you normally run with 'set -u'?  What does 'echo $-' say?  When you
reran ./configure, was it from a fresh unpacking, or were there leftovers
from your first attempt?

| 5)  I tried using make -k to build M4 and it gives me the same error.

What does 'grep SHELL Makefile config.log' say?
How about 'make --version'?

|
(Continue reading)

Chan, Lawson | 30 Jan 23:26 2008

RE: 'set -u' and $SHELL in makefiles [was: GNU M4]

Hi Eric,

1)  actually, I use the following commands to start the execution.  So I am in the bash shell.
    Bash
    ./configure
    make
    Even though I am in the bash shell, running the 'env | grep SHELL' gives SHELL=/usr/bin/ksh
2)  $echo $- returns bhimCBH
3)  I normally don't run set -u.  I still don't know why it is set initially.
4)  I run ./configure in a fresh location and it behaves the same.
5)  The output of 'grep SHELL Makefile config.log' is attached in this email.
6)  I am using make 3.81.

Thanks,

Lawson

-----Original Message-----
From: Eric Blake [mailto:ebb9 <at> byu.net]
Sent: Wednesday, January 30, 2008 4:24 PM
To: Chan, Lawson
Cc: bug-m4 <at> gnu.org; gary <at> gnu.org; bug-automake <at> gnu.org
Subject: Re: 'set -u' and $SHELL in makefiles [was: GNU M4]

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

According to Chan, Lawson on 1/30/2008 1:19 PM:
| Hi Eric,
|
(Continue reading)

Eric Blake | 31 Jan 00:18 2008
Picon

Re: 'set -u' and $SHELL in makefiles [was: GNU M4]


According to Chan, Lawson on 1/30/2008 3:26 PM:
| Hi Eric,
|
| 1)  actually, I use the following commands to start the execution.  So I
am in the bash shell.
|     Bash
|     ./configure
|     make
|     Even though I am in the bash shell, running the 'env | grep SHELL'
gives SHELL=/usr/bin/ksh

Makes sense - bash doesn't overwrite SHELL if it was already set when bash
started.  But there's no need to start bash before running ./configure; it
should run just fine from ksh (or even the hideous Solaris 8 /bin/sh),
since the first part of ./configure is all about discovering a decent
shell if the current shell was not good enough.

| 2)  $echo $- returns bhimCBH
| 3)  I normally don't run set -u.  I still don't know why it is set
initially.

It's not.  Since $- doesn't contain u, 'set -u' is not active.

| 4)  I run ./configure in a fresh location and it behaves the same.
| 5)  The output of 'grep SHELL Makefile config.log' is attached in this
email.

And it shows merely "SHELL = /bin/bash".  No hint of -u, but configure did
decide that /bin/bash was a better choice than /bin/sh.
(Continue reading)


Gmane