gmane.comp.gnu.m4.bugs

RE: In -P mode (m4)

John Sørland — 2013-05-23T18:48:10

Thanks!

This time = SUCCESS! ☺

Br,
John..

From: Gary V. Vaughan [mailto:gary< at >vaughan.pe]
Sent: 16. mai 2013 10:48
To: John Sørland
Cc: bug-m4< at >gnu.org
Subject: Re: In -P mode (m4)

On 15 May 2013, at 16:42, John Sørland <jsl< at >nsm.aero<mailto:jsl< at >nsm.aero>> wrote:
During ./configure of flex-2.5.37 on the raspberrypi I get an error:

“M4 that supports –P”

M4 (latest) is built with success…
Any tip/hint?

 $ export M4=`which gm4`
 $ if test -z "$M4" || test -z "`$M4 --help 2>&1 |grep prefix-builtins 2>/dev/null`"; then M4=`which m4`; fi
 $ $M4 --help |grep prefix-builtins

If the last command above is a string containing prefix-builtins, they building flex with M4 set like that. Otherwise download ftp://ftp.gnu.org/gnu/m4/m4-1.4.16.tar.gz, unpack it, configure with:

 $ ./configure --prefix=$HOME --program-transform-name='s|^|g|'
 $ make all install
 $ export M4=$HOME/bin/gm4

And try building flex again.

HTH,
--
Gary V. Vaughan (gary AT vaughan DOT pe)

Re: Build fails with recent glibc due to outdated gnulib

Amit — 2013-05-16T07:58:14



How I use this patch. I have tried both m4-1.4.16.tar.gz and the latest one 
m4-latest.tar.gz but I always get this same error while trying to install 
it.. Please help me ..

Re: In -P mode (m4)

Gary V. Vaughan — 2013-05-16T08:47:46


On 15 May 2013, at 16:42, John Sørland <jsl< at >nsm.aero> wrote:


 $ export M4=`which gm4`
 $ if test -z "$M4" || test -z "`$M4 --help 2>&1 |grep prefix-builtins 2>/dev/null`"; then M4=`which m4`; fi
 $ $M4 --help |grep prefix-builtins

If the last command above is a string containing prefix-builtins, they building flex with M4 set like that. Otherwise download ftp://ftp.gnu.org/gnu/m4/m4-1.4.16.tar.gz, unpack it, configure with:

 $ ./configure --prefix=$HOME --program-transform-name='s|^|g|'
 $ make all install
 $ export M4=$HOME/bin/gm4

And try building flex again.

HTH,

Re: In -P mode (m4)

Eric Blake — 2013-05-16T11:52:12

[Please don't top-post on technical lists]


That version should work.


I don't have a raspberry pi to reproduce the setup, but you didn't give
me enough details to determine why your configure script failed.

Can you provide more context, such as the section of config.log that
mentions where it is looking for m4, including the full trace of what
commands it tried and error messages it got?

RE: In -P mode (m4)

John Sørland — 2013-05-16T10:55:55

Thanks!

Version no.: 1.4.16..

I 'll try further on!


Br,
John..

-----Original Message-----
From: Eric Blake [mailto:eblake< at >redhat.com] 
Sent: 15. mai 2013 23:20
To: John Sørland
Cc: bug-m4< at >gnu.org
Subject: Re: In -P mode (m4)

On 05/15/2013 03:42 AM, John S  rland wrote:

What does 'm4 --version' say?  Did you build from a tarball or from m4.git?  As there are multiple branches in m4.git, I'd personally recommend building from branch-1.4, as the other branches have not been maintained as well.

In -P mode (m4)

John Sørland — 2013-05-15T09:42:14

During ./configure of flex-2.5.37 on the raspberrypi I get an error:

"M4 that supports -P"


M4 (latest) is built with success...
Any tip/hint?

Br,
John..



[cid:image001.png< at >01CE5161.3EACC270]

Re: In -P mode (m4)

Eric Blake — 2013-05-15T21:19:59

What does 'm4 --version' say?  Did you build from a tarball or from
m4.git?  As there are multiple branches in m4.git, I'd personally
recommend building from branch-1.4, as the other branches have not been
maintained as well.

In -P mode (m4)

John Sørland — 2013-05-15T09:42:14

During ./configure of flex-2.5.37 on the raspberrypi I get an error:

"M4 that supports -P"


M4 (latest) is built with success...
Any tip/hint?

Br,
John..

Re: Bootstrap issues

Stefano Lattarini — 2013-04-24T09:06:25

Gaaahh, forget it.  I erroneously tried to bootstrap the 'master' branch rather
than the 'branch-1.4' branch.  Everything works perfectly fine with on 'branch-1.4'.

Sorry again for then noise,
  Stefano

Bootstrap issues

Stefano Lattarini — 2013-04-24T08:45:29

With automake 1.13.1, there are these issues:

  configure.ac:149: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed.
  configure.ac:149: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
  configure.ac:149: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
  >
  > These are basically noise, safe to ignore, will disappear once the required Gettext
  > version is upgraded; and plans for removal of AM_PROG_MKDIR_P have been dropped, so
  > this warning won't become a fatal error anyway.  I think it's best to just ignore it.

  Makefile.am:152: error: 'pkglibexecdir' is not a legitimate directory for 'LTLIBRARIES'
  >
  > This is a hard error, and is causing the actual failure

  Makefile.am:158: warning: variable 'EXTRA_modules_gnu_la_SOURCES' is defined but no program or
  Makefile.am:158: library has 'modules_gnu_la' as canonical name (possible typo)
  Makefile.am:166: warning: variable 'EXTRA_modules_m4_la_SOURCES' is defined but no program or
  Makefile.am:166: library has 'modules_m4_la' as canonical name (possible typo)
  ... (and scores of similar warnings).
  >
  > I haven't investigated these.

  ...
  parallel-tests: installing 'build-aux/test-driver'
  autoreconf: automake failed with exit status: 1
  bootstrap: autoreconf failed
  >
  > This is what bootstrap reports on the stdout/stderr, but than it exists
  > with status 0.  Yikes!

HTH,
  Stefano

Re: large diversions broken on mingw

Eric Blake — 2013-03-11T16:36:29

Fixed as of this commit, although I'm still seeing some issues in gnulib
when building for mingw.

https://lists.gnu.org/archive/html/m4-patches/2013-03/msg00003.html

Re: make check failure on HPUX-11.23 and HPUX-11.31

Gary V. Vaughan — 2013-03-11T14:40:08

Hi Eric,

On 11 Mar 2013, at 19:54, Eric Blake <eblake< at >redhat.com> wrote:

I'm fine with your just making it skip on HPUX >= 11.23 if a portable fix
is not straight forward.

Cheers,

Re: make check failure on HPUX-11.23 and HPUX-11.31

Eric Blake — 2013-03-11T12:54:31


Hmm.  POSIX says that we can't rely on >&- closing stdout; it works on
most platforms, but HPUX apparently ignores the request and reopens
stdout to /dev/null, and POSIX allows this behavior.  The test is too
strict, and should be checking whether it is possible to start a program
with stdout closed before requiring a particular behavior in that
condition (since HPUX has no way to get into that condition).


I'll see what I can come up with today.  If I don't come up with a way,
then it is safe to ignore.

Re: [PATCH] make check failure on Tru64 Unix

Gary V. Vaughan — 2013-03-11T05:58:21

Hi Paul,

On 11 Mar 2013, at 12:31, Paul Eggert <eggert< at >cs.ucla.edu> wrote:

Pushed.  Thank you.

Cheers,

[PATCH] make check failure on Tru64 Unix

Gary V. Vaughan — 2013-03-11T05:18:36

M4 master with latest gnulib is not picking up gnulib strtod for some
reason, even though it is compiled and added to libm4.a on this platform:

tru64% make check
...
Checking ./180.format                                                     
< at > ../doc/m4.texi:6069: Origin of test
./180.format: stdout mismatch
*** m4-tmp.93382/m4-xout        Mon Mar 11 02:50:45 2013
--- m4-tmp.93382/m4-out Mon Mar 11 02:50:45 2013
***************
*** 5,8 ****
  5000
  success
  success
! 20
--- 5,8 ----
  5000
  success
  success
! 0
< at > ../doc/m4.texi:6069: Origin of test
./180.format: stderr mismatch
*** m4-tmp.93382/m4-xerr        Mon Mar 11 02:50:45 2013
--- m4-tmp.93382/m4-err Mon Mar 11 02:50:45 2013
***************
*** 0 ****
--- 1 ----                                 
+ m4:stdin:12: non-numeric argument 0xa.P+1
Checking ./181.format                      
...
Failed checks were:
  ./180.format:out ./180.format:err
...

So the format builtin is not working:

tru64% src/m4
format(`%g', `0xa.P+1')
./m4:stdin:1: non-numeric argument 0xa.P+1
0

Which is due to the system strtod being used:

tru64% cat x.c
#include <stdio.h>
#include <stdlib.h>
void main () { printf("%g,%g\n", 0xa.P+1, strtod("0xa.P+1", NULL)); }
tru64% cc x.c && ./a.out
20,0
tru64% { echo '#include <config.h>'; cat x.c; } > y.c
tru64% cc -Ilib y.c lib/libm4.a && ./a.out
20,20
tru64% { echo '#include "m4.h"'; cat x.c; } > z.c
tru64% cc -Ilib -Isrc z.c lib/libm4.a && ./a.out
20,0

I bisected my way to this fix in gnulib/lib/unistd.h.in:

--- lib/unistd.in.h.orig        2013-03-11 05:09:57.035508275 +0000            
+++ lib/unistd.in.h     2013-03-11 04:53:49.489269636 +0000                    
< at >< at > -62,7 +62,8 < at >< at >                                                              
    <unistd.h>.  */                                                            
 /* Solaris declares getcwd not only in <unistd.h> but also in <stdlib.h>.  */ 
+/* OSF Tru64 Unix cannot see gnulib rpl_strtod when system <stdlib.h> is included here. */
 /* But avoid namespace pollution on glibc systems.  */                        
-#ifndef __GLIBC__                                                             
+#if !defined __GLIBC__ && !defined __osf__                                    
 # define __need_system_stdlib_h                                               
 # include <stdlib.h>                                                          
 # undef __need_system_stdlib_h                                                

After reconfiguring and building with this patch, m4 now picks up the working
gnulib strtod:

tru64% src/m4
format(`%g', `0xa.P+1')
20

And the full testsuite (gnulib tests and all) passes on this platform now.

Any objections if I push the fix?

Cheers,

make check failure on HPUX-11.23 and HPUX-11.31

Gary V. Vaughan — 2013-03-11T03:19:50

Hi Eric,

I don't really understand the nuances of this test enough to debug
any further.  It looks like the expectations are too tight by
requiring an error rather than a silent failure.  WDYT?

hpux% make check
...
Checking ./004.command_li
Checking ./005.command_li
< at > ../doc/m4.texi:992: Origin of test
./005.command_li: stdout mismatch
*** m4-tmp.18651/m4-xout        Mon Mar 11 02:47:38 2013
--- m4-tmp.18651/m4-out Mon Mar 11 02:47:38 2013
***************
*** 1 ****
! 1
--- 1 ----
! 0
Checking ./006.command_li
...
Failed checks were:
  ./005.command_li:out
...
hpux% echo nothing | ./src/m4 >&-
hpux% echo $?
0
hpux% bash
bash-4.2$ echo nothing | ./src/m4 >&-
bash-4.2$ echo $?
0

Curiously, this test behaves as expected on HPUX-11.11 and 11.00.
Safe to ignore?  Can the test case be fixed?

Cheers,

Re: large diversions broken on mingw

Eric Blake — 2013-03-09T23:09:20

More details - it looks like this has been around for a long time -
gnulib has used _O_TEMPORARY when opening files on mingw, which has the
effect of deleting the file on the first fclose().  But m4 needs the
file to exist even after we close it, which means we should not be using
_O_TEMPORARY.  I'm trying to figure out whether the patch needs to be in
gnulib, m4, or both.

large diversions broken on mingw

Eric Blake — 2013-03-09T15:12:30

Just a heads up that I'm trying to fix a bug in diversion handling,
exposed by 'make check', but which only shows on mingw or other
platforms where rename() can't change the name of an open file.  Most
Unix systems are unaffected, and I doubt many people test on mingw,
which is probably why no one has reported it even though I think the bug
has been present for months.

I'm still trying to ascertain whether released m4 has the bug, or
whether it is a regression introduced by a recent gnulib update.  But
the gdb session shows what is happening - if a diversion is large enough
to spill to a file, the act of closing it prior to the rename happens to
trigger a path that accidentally unlink()s the file.  I hope to have the
patch posted by Monday.

Starting program: /home/eblake/m4-branch/buildm64/src/m4 -I ../examples/
../checks/146.diversions
[New Thread 1476.0x348]

Breakpoint 1, m4_tmprename (oldnum=9001, newnum=9002) at
../../src/output.c:340
340  char *oldname = xstrdup (m4_tmpname (oldnum));
(gdb) n
341  const char *newname = m4_tmpname (newnum);
(gdb)
342  register_temp_file (output_temp_dir, newname);
(gdb) p oldname
$7 = 0xa4bbc8 "K:\\cygwin-2\\tmp/m4-zHYjYe/m4-9001"
(gdb) p newname
$8 = 0x39650 "K:\\cygwin-2\\tmp/m4-zHYjYe/m4-9002"
(gdb) shell ls /tmp/m4-zHYjYe
m4-9001
(gdb) n
343  if (oldnum == tmp_file1_owner)
(gdb)
356  else if (oldnum == tmp_file2_owner)
(gdb)
363          if (close_stream_temp (tmp_file2))
(gdb) s
close_stream_temp (fp=0x77c5fd00) at ../../lib/clean-temp.c:776
776  int fd = fileno (fp);
(gdb) n
779  int result = close_stream (fp);
(gdb)
780  int saved_errno = errno;
(gdb)
785  unregister_fd (fd);
(gdb)
787  errno = saved_errno;
(gdb)
788  return result;
(gdb) shell ls /tmp/m4-zHYjYe
(gdb)

RE: GNU M4 Install

Alexander Gonzalez — 2013-02-28T15:35:52

Yes, this all started as a project to get Apache244 and tomcat 7 to talk to each other on Windows 7. Rather than installing a grouped package like xampp I decided to install standalone versions. Only issue though is that to get mod_jk (the connector), it seemed I would have to build Apache to get AXPS which didn't seem it was available in their tarballs. This led to the requirement to build apr and apr-util which led to the requirement to build autoconf which needs to have M4. (I think I got that straight).

Thanks I will see if I can set up a Linux VM to do the compiling then, worse comes to worse I will have to install XAMPP

Alex


-----Original Message-----
From: Eric Blake [mailto:eblake< at >redhat.com] 
Sent: Thursday, February 28, 2013 9:26 AM
To: Alex Gonzalez
Cc: bug-m4< at >gnu.org
Subject: Re: GNU M4 Install

On 02/27/2013 10:11 PM, Alex Gonzalez wrote:

Why aren't you using the m4 pre-built for cygwin?


Oh, you aren't compiling for cygwin.  You're trying to do a cross-compiler build for mingw.  In which case, this is not a cygwin question, but a cross-build question related to mingw.

Most likely, this is a situation where no one has ever cross-compiled -
m4 1.4.16 was released before the 64-bit mingw project took off, so while modern gnulib may be able to cope with this situation, the version of gnulib used at the time of the m4 release obviously does not.  It's been ages since I've attempted to do a cross-compile to mingw, but as I need to release m4 1.4.17 sometime anyways to resolve FTBFS on modern glibc, I'll try and do that before making a release.

Re: GNU M4 Install

Eric Blake — 2013-02-28T15:26:15

Why aren't you using the m4 pre-built for cygwin?


Oh, you aren't compiling for cygwin.  You're trying to do a
cross-compiler build for mingw.  In which case, this is not a cygwin
question, but a cross-build question related to mingw.

Most likely, this is a situation where no one has ever cross-compiled -
m4 1.4.16 was released before the 64-bit mingw project took off, so
while modern gnulib may be able to cope with this situation, the version
of gnulib used at the time of the m4 release obviously does not.  It's
been ages since I've attempted to do a cross-compile to mingw, but as I
need to release m4 1.4.17 sometime anyways to resolve FTBFS on modern
glibc, I'll try and do that before making a release.

GNU M4 Install

Alex Gonzalez — 2013-02-28T05:11:57

Hello,

on windows 7 - 64
using CYGWIN 1.7.17-1
trying to install m4 1.4.16

I have been able to download the m4 package through the cygwin gui (home
dir = c:\cygwin\home\alex\m4\) and directly by extracting to c:\m4. I am
able to run ./configure in both cases in the local directories but the make
process doesn't work and fails each time

these are the last lines of the make process -- attached is the config log
from my last attempt

C:\cygwin\home\alex\m4-1.4.16\lib/wait-process.c:298: undefined reference
to `waitpid'
collect2: ld returned 1 exit status
Makefile:1113: recipe for target `m4.exe' failed
make[2]: *** [m4.exe] Error 1
make[2]: Leaving directory `/home/alex/m4-1.4.16/src'
Makefile:1131: recipe for target `all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alex/m4-1.4.16'
Makefile:1084: recipe for target `all' failed
make: *** [all] Error 2 t

I usually pride myself in being able to find resources on builds but in
this case I would really appreciate a hand

Thanks,

Alex