Re: 4.3.90 release candidate segfaults on linux and solaris

2022-09-26 Thread Denis Excoffier 



> On 2022-09-25 16:25, Dmitry Goncharov wrote:
> 
> On Sun, Sep 25, 2022 at 2:09 AM Martin Dorey
>  wrote:
>> And vfork is where that happens.  If I’ve followed the thicket of #ifdef 
>> correctly and understood the vfork man page, then this is illegal when using 
>> vfork:
>> 
>> https://github.com/mirror/make/blob/master/src/job.c#L2556
> 
> 
> Thanks, Martin.
> This is indeed the culprit.
> I was able to find a linux where this reproduces. However, the this
> does this reproduce on my sun. Denis, can you please try this patch on
> your sun?
> 
> regards, Dmitry
> 
> Here is a patch
> 
> index d12a9138..1ed71f0a 100644
> --- a/src/job.c
> +++ b/src/job.c
> @@ -2286,6 +2286,8 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>   posix_spawnattr_t attr;
>   posix_spawn_file_actions_t fa;
>   short flags = 0;
> +#else
> +  char **parent_environ = environ;
> #endif
> 
>   /* Divert child output if we want to capture it.  */
> @@ -2301,7 +2303,12 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
> 
>   pid = vfork();
>   if (pid != 0)
> +{
> +  /* The child sets environ to child->environment before calling execvp.
> +   * Restore it here.  */
> +  environ = parent_environ;
>   return pid;
> +}
> 
>   /* We are the child.  */
>   unblock_all_sigs ();
> @@ -2552,7 +2559,8 @@ exec_command (char **argv, char **envp)
> errno = ENOEXEC;
> 
> # else
> -  /* Run the program.  */
> +  /* Run the program.
> +   * The parent has to restore environ.  */
>   environ = envp;
>   execvp (argv[0], argv);

Hello,
This patch works perfectly, both on my 32bit linux and my 32bit solaris 10.
Thank you.
Regards,
Denis Excoffier.

Re: 4.3.90 release candidate segfaults on linux and solaris

2022-09-24 Thread Denis Excoffier 


> On 2022-09-24 17:19, Paul Smith wrote:
> 
> On Sat, 2022-09-24 at 09:36 +0200, Denis Excoffier wrote:
>> In my specific configuration (under linux, with --disable-nls,
>> --disable-load, without using -j, using 'env -i make -d -n'), a
>> segfault always occurs around line 118 of src/expand.c:
>> 
>> My linux is old (2.6.32),
> 
> The kernel version is not very interesting for a userspace program like
> GNU make.  But, it would be interesting if you could provide the
> version of libc you are using; on my system I can use:
> 
>  ~$ /lib/x86_64-linux-gnu/libc.so.6 --version | head -n1
> 
> You can find the library by running "ldd make | grep libc'
> 
> It's also interesting you're running with "env -i" that seems like it
> might be related.  Do you get the crash if you run without that?
> 
> A quick check on my system was not able to show any issues using the
> same setup as you, even building make with ASAN.  I will review the
> code especially around memory handling in the child structures to see
> if I can find an error by inspection.

% ldd make
linux-gate.so.1 (0xb76e4000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7565000)
/lib/ld-linux.so.2 (0xb76e5000)
% /lib/i386-linux-gnu/libc.so.6 --version | head -2
GNU C Library (Debian GLIBC 2.19-18+deb8u10) stable release version 2.19, by 
Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
%

The segfault also occurs without ‘env -i’. I was just trying to minimize the 
number of
entries in the environment. In any case make seems to always add a few ones
by default (like MAKEFLAGS etc.).

The crashes in solaris and linux are so similar, and go away also so similarly,
that i would primarily think about size of types. Under cygwin and
MacOS all sizes (pointers, long int, size_t, SIZE_MAX, time_t) are 8, while
under (this) solaris and (this) linux all sizes are 4. Only size of int is 4 on 
all.

Regards,

Denis Excoffier.

4.3.90 release candidate segfaults on linux and solaris

2022-09-24 Thread Denis Excoffier 
Hello,

At the beginning, i found a segfault in the source code of autoconf-2.71.

I reduced the case and the current test Makefile is as follows:

% cat Makefile
export PATH = $(shell echo "`pwd`/tests:$$PATH")
foo = $(shell echo yes)

all:
echo $(foo)
%

In my specific configuration (under linux, with --disable-nls,
--disable-load, without using -j, using 'env -i make -d -n'), a
segfault always occurs around line 118 of src/expand.c:

for (ep = environ; *ep != 0; ++ep)
  if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
return xstrdup ((*ep) + nl + 1);

This is new code, which seems ok, but segfault occurs because in this
environment, some *ep, while not null, is definitely not a
string (e.g. i found *ep = 0x18).

I suppose the environment got corrupted before that. Indeed, several
binary chars appear in the debug printouts with my instrumented code.
However, i was not able to figure out the root cause.

One way to circumvent temporarily the problem is
to comment out the two instances of free_childbase().
After that, the segfault completely disappears, even
with -j, and also under all the tests i can perform here in
compiling many GNU projects and also my own tools.

My linux is old (2.6.32), solaris is solaris 10 (old too...)
Under MacOS (12.6) and Cygwin (3.3.6) no segfault at all.

Hoping someone will be able to track this further.

Regards,

Denis Excoffier.

Re: GNU make 4.0.90 prerelease available

2014-10-02 Thread Denis Excoffier 

On 2014-10-01 20:03, Eli Zaretskii wrote:

>> From: Denis Excoffier 
>> Date: Wed, 1 Oct 2014 19:55:13 +0200
>> 
>> For me, under Cygwin, i had to apply the following in order to compile (GCC 
>> 4.9.1):
>> 
>> diff -uNrp make-4.0.90-original/job.c make-4.0.90-patched/job.c
>> --- make-4.0.90-original/job.c   2014-09-30 14:18:39.0 +0200
>> +++ make-4.0.90-patched/job.c2014-10-01 19:42:12.0 +0200
>> @@ -2694,7 +2694,7 @@ construct_command_argv_internal (char *l
>>   /* This is required if the MSYS/Cygwin ports (which do not define
>>  WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses
>>  sh_chars_sh directly (see below).  */
>> -  static const char *sh_chars_sh = sh_chars;
>> +  const char *sh_chars_sh = sh_chars;
>> # endif  /* HAVE_DOS_PATHS */
>> #endif
>>   int i;
> 
> What happens if you don't?
> 
Otherwise i get the following:

job.c: In function 'construct_command_argv_internal':
job.c:2697:3: error: initializer element is not constant
  static const char *sh_chars_sh = sh_chars;
  ^
make[2]: *** [job.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This occurs with GCC 4.9.1 and also with the regular /usr/bin/gcc on cygwin 
(GCC 4.8.3).

Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 4.0.90 prerelease available

2014-10-01 Thread Denis Excoffier 

On 2014-10-01 17:37, Eli Zaretskii wrote:

>> From: Paul Smith 
>> Date: Tue, 30 Sep 2014 09:56:47 -0400
>> 
>> The first pre-release GNU make 4.0 is available on the alpha FTP site
>> (or via HTTP):
>> 
>> 6df6ca5791437cd3212c21872ddc29cb  
>> ftp://alpha.gnu.org/gnu/make/make-4.0.90.tar.gz
>> 6df10668d06f9a2ef152995bd5b577e4  
>> ftp://alpha.gnu.org/gnu/make/make-4.0.90.tar.bz2
>> 
>> This release is mainly bug fixes.
> 
> Looks good on MS-Windows (I fixed a few minor issues, most of them
> specific to the MS-Windows build).
> 
> 
For me, under Cygwin, i had to apply the following in order to compile (GCC 
4.9.1):

diff -uNrp make-4.0.90-original/job.c make-4.0.90-patched/job.c
--- make-4.0.90-original/job.c  2014-09-30 14:18:39.0 +0200
+++ make-4.0.90-patched/job.c   2014-10-01 19:42:12.0 +0200
@@ -2694,7 +2694,7 @@ construct_command_argv_internal (char *l
   /* This is required if the MSYS/Cygwin ports (which do not define
  WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses
  sh_chars_sh directly (see below).  */
-  static const char *sh_chars_sh = sh_chars;
+  const char *sh_chars_sh = sh_chars;
 # endif  /* HAVE_DOS_PATHS */
 #endif
   int i;


Regards,

Denis Excoffier.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make check under Cygwin (3.99.93)

2013-10-01 Thread Denis Excoffier 

Hello,

Thank you for this new RC.

I have tested make-3.99.93 under cygwin 32 bits with --disable-load
(and without the spawn-patch).

Several items that i had reported in
http://lists.gnu.org/archive/html/bug-make/2013-09/msg00110.html
(and for which i didn't get any feedback) are still there.

I'm especially asking for
- item 1 (duplication of "$code != -1") and
- item 3 (jobserver test fails if HOME is not set)
- and, if possible, implementation of ${abspath /foo} == /foo

Also, for information with the spawn-patch, the output-sync test still
fails (like for 3.99.92, this is not unexpected), but now (with 
3.99.93)

the GNUMAKEFLAGS test also fails.

Regards,

Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make check under Cygwin

2013-09-26 Thread Denis Excoffier 

On 2013-09-25 14:44, Eli Zaretskii wrote:

If no one steps forward, I will try to find time to fix this soon.
Stay tuned, and thanks for your contributions.

The most needed thing to fix is
${abspath /foo}
that currently returns "/cy/foo"

Regards,

Denis Excoffier.





___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make check under Cygwin

2013-09-25 Thread Denis Excoffier 

Still experimenting 'make check' with Cygwin (without the spawn-patch,
with --disable-load):

1) In test_driver.pl, line 486 (look for "Test returned"), a comparison
of $code against the value -1 is performed. However, 3 lines above the 
same

test is done. This looks strange.

I wonder if what is meant couldn't be
elsif ($code != 1 && $code != 0) {
instead of
elsif ($code != 1 && $code != -1) {

2) In connection with (1) above, the category 'default_names' produces
'*** Test returned 0' and this is considered to be $suite_passed = 0
(no deletion of files, no incrementation of categories_passed etc.),
however the category seems to pass since the "ok" string is printed.

If i apply (1) above, all is ok.
I don't understand why this "Test returned 0" does not show up
on other (eg Linux) platforms.

3) If the HOME env var is not set, one of the jobserver tests fails.
Perhaps this test should not be launched if HOME is not set.

4) If i do _not_ apply the following patch:

% type patch
diff -uNr make-3.99.92-original/configure 
make-3.99.92-patched/configure

--- make-3.99.92-original/configure 2013-09-23 06:50:50.0 +0159
+++ make-3.99.92-patched/configure  2013-09-25 11:12:37.020859600 +0159
@@ -7817,7 +7817,7 @@
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */

-#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && 
!defined __EMX__ && !defined __MSYS__ && !defined __CYGWIN__
+#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && 
!defined __EMX__ && !defined __MSYS__

 neither MSDOS nor Windows nor OS2
 #endif

%

i obtain the following errors:
- output-sync (8/13 passed)
- recursion (1/2 passed)
- abspath (0/1 passed)
- MAKE (0/1 passed)

5) That's all.


With the spawn-patch installed, the output-sync test fails, but this
is another story i suppose.

Hope this helps,

Regards,

Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

2013-09-24 Thread Denis Excoffier 
On 2013-09-24 17:15, David Boyce wrote:
> I'm not sure if Pavel is on this list so adding him explicitly.
This was done.
> 
> Looks like there's a strong risk that no version of the spawn patch will get 
> into 4.0 which would be a shame IMHO.
True. However, we'll probably be able to circulate a "spawn-patch" like under 
the previous 'make' versions.
> 
> -David
Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

2013-09-24 Thread Denis Excoffier 
On 2013-09-24 16:37, Frank Heckenbach wrote:
> Try this patch. I don't use EMX myself, but I noticed this when
> reading through the lastest changes, and it seems to fit your bug
> description.
> 
> --- function.c.orig   2013-09-22 07:53:27.0 +0200
> +++ function.c2013-09-24 16:21:37.0 +0200
> @@ -1710,7 +1710,7 @@
>   CLOSE_ON_EXEC(pipedes[1]);
>   CLOSE_ON_EXEC(pipedes[0]);
>   /* Never use fork()/exec() here! Use spawn() instead in exec_command() */
> -  pid = child_execute_job (FD_STDIN, pipedes[1], FD_STDOUT, command_argv, 
> envp);
> +  pid = child_execute_job (FD_STDIN, pipedes[1], FD_STDERR, command_argv, 
> envp);
>   if (pid < 0)
> perror_with_name (error_prefix, "spawn");
> # else /* ! __EMX__ */
> 
Thank you for pointing this. I should have seen it.

All my tests now pass. I suppose we are at it. Here is the emx-patch, to apply
on make-3.99.92 in order to have a working EMX platform (i suppose). I can say 
that
the spawn-patch applies (still very easily) on top of this and the resulting 
'make'
seems to work well.

% type emx-patch
diff -uNr make-3.99.92-original/function.c make-3.99.92-patched/function.c
--- make-3.99.92-original/function.c2013-09-22 23:10:37.0 +0159
+++ make-3.99.92-patched/function.c 2013-09-24 17:41:53.988328300 +0159
@@ -1710,7 +1710,7 @@
   CLOSE_ON_EXEC(pipedes[1]);
   CLOSE_ON_EXEC(pipedes[0]);
   /* Never use fork()/exec() here! Use spawn() instead in exec_command() */
-  pid = child_execute_job (FD_STDIN, pipedes[1], FD_STDOUT, command_argv, 
envp);
+  pid = child_execute_job (FD_STDIN, pipedes[1], FD_STDERR, command_argv, 
envp);
   if (pid < 0)
 perror_with_name (error_prefix, "spawn");
 # else /* ! __EMX__ */
diff -uNr make-3.99.92-original/job.c make-3.99.92-patched/job.c
--- make-3.99.92-original/job.c 2013-09-21 23:27:13.0 +0159
+++ make-3.99.92-patched/job.c  2013-09-24 17:41:53.894577700 +0159
@@ -2234,7 +2234,7 @@
   /* Restore stdout/stdin/stderr of the parent and close temporary FDs.  */
   if (save_stdin >= 0)
 {
-  if (dup2 (save_stdin, FD_STDIN) != 0)
+  if (dup2 (save_stdin, FD_STDIN) != FD_STDIN)
 fatal (NILF, _("Could not restore stdin\n"));
   else
 close (save_stdin);
@@ -2242,7 +2242,7 @@
 
   if (save_stdout >= 0)
 {
-  if (dup2 (save_stdout, FD_STDOUT) != 0)
+  if (dup2 (save_stdout, FD_STDOUT) != FD_STDOUT)
 fatal (NILF, _("Could not restore stdout\n"));
   else
 close (save_stdout);
@@ -2250,7 +2250,7 @@
 
   if (save_stderr >= 0)
 {
-  if (dup2 (save_stderr, FD_STDERR) != 0)
+  if (dup2 (save_stderr, FD_STDERR) != FD_STDERR)
 fatal (NILF, _("Could not restore stderr\n"));
   else
 close (save_stderr);
diff -uNr make-3.99.92-original/job.h make-3.99.92-patched/job.h
--- make-3.99.92-original/job.h 2013-09-21 23:27:13.0 +0159
+++ make-3.99.92-patched/job.h  2013-09-24 17:41:53.800827100 +0159
@@ -128,7 +128,7 @@
 # define FD_STDERR  (fileno (stderr))
 # if defined(__EMX__)
 int child_execute_job (int stdin_fd, int stdout_fd, int stderr_fd,
-   char **argv, char **envp)
+   char **argv, char **envp);
 # else
 void child_execute_job (int stdin_fd, int stdout_fd, int stderr_fd,
 char **argv, char **envp) __attribute__ ((noreturn));
%


Regards,

Denis Excoffier.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

2013-09-24 Thread Denis Excoffier 
On 2013-09-24 07:40, Eli Zaretskii wrote:
> Could be, as I don't think I've seen any EMX-related changes for a
> long time.
On the contrary, child_execute_job() has been much rewritten between
make-3.99.91 and make-3.99.92.

First, in job.c,
if (dup2 (save_stdout, FD_STDOUT) != 0)
should be modified into
if (dup2 (save_stdout, FD_STDOUT) != FD_STDOUT)
and similarly for save_stderr (and save_stdin).

With this modification (and the spawn-patch), this is now better and
'make' works if the shell function does not return anything
(eg ${shell touch /tmp/bar}). But if it does:

% cat Makefile
foo := ${shell date}
all:
  @echo ${foo}${foo}
%

i obtain

% make
date: write error: Bad file descriptordate: write error: Bad file descriptor
%


Now, magically, if i apply:

% cat patch0
diff -uNr make-3.99.92-original/job.c make-3.99.92-patched/job.c
--- make-3.99.92-original/job.c 2013-09-21 23:27:13.0 +0159
+++ make-3.99.92-patched/job.c  2013-09-24 11:40:48.432981000 +0159
@@ -2214,7 +2214,7 @@
   CLOSE_ON_EXEC (stdout_fd);
 }
 
-  if (stderr_fd != FD_STDERR)
+  if (0 && stderr_fd != FD_STDERR)
 {
   if (stderr_fd != stdout_fd)
 {
%

the Makefile above (and all the real examples that i have tested so
far) seem to work. Hence, the treatement for stderr must be
erroneous somewhere. I've performed several trials, adding or removing
some code in this area, but didn't manage to make things better.

I'm not so familiar with that kind of plumbing, if someone could see
what is going on... Pavel?

Regards,

Denis Excoffier.



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

2013-09-23 Thread Denis Excoffier 
On 2013-09-23 19:29, Paul Smith wrote:
>> Also a semicolon seems to be missing after the declaration of
>> child_execute_job() in the case '# if defined(__EMX__)'.
> 
> Oops.  Thanks.
I applied the spawn-patch (by hand since many hunks), mentioned in
http://lists.gnu.org/archive/html/bug-make/2013-08/msg00012.html

Compilation succeeds and a very simple Makefile with no
shell functions succeeds. But even a simple shell function like

foo := ${shell date}

kills the make, with no error message (since stderr is closed i
suppose). With `make -O`, an error message "Could not restore
stdout" is produced.

Since the patch makes merely Cygwin as a copy of EMX, and that
same patch used (with very minor modifications) to work with
make-3.99.91, perhaps this suggests that the EMX platform is
broken under make-3.99.92.

Any hints?

Regards,

Denis Excoffier.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make 3.99.92 release candidate is available

2013-09-23 Thread Denis Excoffier 
On 2013-09-23 10:02, Eli Zaretskii wrote:
> 
> This RC was broken on MS-Windows, because the inversion of OUTPUT_SYNC
> to NO_OUTPUT_SYNC was not done in the w32 subdirectory.  I fixed that
> in git.
> 
> There's also another problem: you added a test script dash-w, where we
> already had a dash-W.  On Windows, these two map to the same file, so
> git overwrites the same file, and the file is always marked as
> "modified".  Please rename one of the files to some other name.
> 

Hello,

In order to compile (with --disable-load) under cygwin i had to
remove two occurrences of "(scm_t_subr)" from guile.c (unknown
identifier, sorry). With --without-guile this is, expectedly,
not needed.

Also a semicolon seems to be missing after the declaration of
child_execute_job() in the case '# if defined(__EMX__)'.

Hope this helps,

Regards,

Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: make check on darwin

2013-09-22 Thread Denis Excoffier 

On 2013-09-22 06:50, Paul Smith wrote:
> Just curious: did you build with --disable-load because something failed
> otherwise?  Or just because you wanted to?
I didn't investigate the errors produced with --enable-load. Here they are:

features/load ... Error running 
/Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 0; got 512): 
/Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f work/features/load.mk
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/load.mk.1
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/load.mk.2
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/load.mk.3
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/load.mk.4
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/load.mk.5
FAILED (0/6 passed)
features/loadapi  Error running 
/Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 0; got 512): 
/Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/loadapi.mk
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/loadapi.mk.1
Error running /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make (expected 
0; got 512): /Users/denis/darlcl/tmp/make/make-3.99.91/tests/../make -f 
work/features/loadapi.mk.2
FAILED (0/3 passed)


and the content of the features directory is attached to this e-mail. I do not 
use clang.

Regards,

Denis Excoffier.



features.tar.xz
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make check on darwin

2013-09-17 Thread Denis Excoffier 
Hello,

I'm currently on x86_64-apple-darwin12.4.0 with make-3.99.91. I use gcc-4.8.1.

I have configured with --disable-load. I had to apply the patch below
(self explanatory i think) for 'make check' to return with no error.

Moreover:
1) when configured with --disable-job-server, the tests in features/parallelism
are however all activated and 'make check' obviously fails (#7 and #10)
2) when some errors are produced, a message is printed to direct the 
user to look for files ending in '.diff'; but many diff-files are actually
named .diff.X, where X is a small number
3) and more importantly, 'make check' begins to write its results on stdout
(eg features/archives..), then seems to switche to stderr for the 
results of the features/archives and all the following text. This is weird.

Hope this helps.

Best regards,

Denis Excoffier.

diff -uNr make-3.99.91-original/tests/scripts/features/archives 
make-3.99.91-patched/tests/scripts/features/archives
--- make-3.99.91-original/tests/scripts/features/archives 2013-09-16 
06:13:27.0 +0200
+++ make-3.99.91-patched/tests/scripts/features/archives  2013-09-17 
23:18:35.0 +0200
@@ -13,7 +13,7 @@

 # Very simple
 run_make_test('all: libxx.a(a1.o)',
-  '', "ar rv libxx.a a1.o\nar: creating libxx.a\na - a1.o\n");
+  '', "ar rv libxx.a a1.o\nar: creating archive libxx.a\na - 
a1.o\n");

 # Multiple .o's.  Add a new one to the existing library
 run_make_test('all: libxx.a(a1.o a2.o)',
diff -uNr make-3.99.91-original/tests/scripts/features/default_names 
make-3.99.91-patched/tests/scripts/features/default_names
--- make-3.99.91-original/tests/scripts/features/default_names  2013-09-16 
06:13:27.0 +0200
+++ make-3.99.91-patched/tests/scripts/features/default_names 2013-09-17 
23:18:35.0 +0200
@@ -13,7 +13,7 @@
 # DOS/WIN32 platforms preserve case, but Makefile is the same file as makefile.
 # Just test what we can here (avoid Makefile versus makefile test).

-if ($port_type eq 'UNIX') {
+if ($port_type eq 'UNIX_BUT_NOT_WITH_MY_FILESYSTEM') {
   # Create another makefile called "makefile"
   open(MAKEFILE,"> makefile");
   print MAKEFILE "SECOND: ; \@echo It chose makefile\n";
@@ -30,7 +30,7 @@
 &compare_output("It chose GNUmakefile\n",&get_logfile(1));
 unlink $makefile;

-if ($port_type eq 'UNIX') {
+if ($port_type eq 'UNIX_BUT_NOT_WITH_MY_FILESYSTEM') {
   &run_make_with_options("","",&get_logfile);
   &compare_output("It chose makefile\n",&get_logfile(1));
   unlink "makefile";


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

minor bug: double period

2013-09-17 Thread Denis Excoffier 
Hello,

% echo "load foo" | make
Makefile: 1: *** The 'load' operation is not supported on this platform..  Stop.
%

No problem with the message. But are the two periods really necessary?

Regards,

Denis Excoffier.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

2013-08-11 Thread Denis Excoffier 

On 2013-08-07 10:52, Pavel Fedin wrote:

> Perhaps some more testing would convince you. Actually i have
> sent the new patch to Denis Excoffier (who reported the bug), but he doesn't
> reply for some reason. If there'll be no response for some more time, i'll
> retry posting the patch on Cygwin ML. I just don't want to be too much
> annoying.
I've applied the new patch, together with the patch for the DOS paths, on top of
make-3.99.90 and everything seems OK now. Thanks.

As a user, i would be fully happy if the behavior could be driven by the
MAKE_USE_SPAWN env. var. (and a similar env. var. in case the default is spawn).
Associated command line options would be unnecessary, but perhaps needed for
completeness. The default being configurable with the (Cygwin only, to be 
checked)
'--enable-spawn=yes|no' parameter to the ./configure program (default=no of 
course).
I suppose we'll also need that 'make --help' reports its default because it 
cannot be
so easily determined (see e.g. the end of 'tar --help') but you may let this 
part
to other people. On the other hand, you'll have to provide full documentation 
under
make.texi.

Please provide something like this as a patch against the HEAD and you'll more
easily convince (i think). Avoid grouping two branches of an #ifdef (eg 
'environ = envp'),
let the maintainers do this (if they prefer to).

After that, it will be time for us to wait for the make-3.99.91 distribution.


Regards,

Denis Excoffier.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make release candidate 3.99.90 available

2013-05-20 Thread Denis Excoffier 

On 2013-05-20 15:16, Paul Smith wrote:
> On Fri, 2013-05-17 at 19:42 +0200, Denis Excoffier wrote:
>> Compared with make-3.82, the new make-3.99.90 breaks those Makefiles,
>> like in tiff-v3.6.1 (rather old i know, before 2003 at least), that
>> use the construction:
>> 
>> make -${MAKEFLAGS}
> 
> Hrm.  This is actually specifically discouraged by the documentation.
> However reading the POSIX standard shows that make is required to accept
> this format, at least for standard arguments.
Perhaps the space in front of "--jobserver-fds" in MAKEFLAGS (make-3.82),
together with the do-nothing "-" target are already there to satisfy the
POSIX standard: just put the space back and that's it?

In the mean time i discovered a few minor documentation bugs:
- in doc/main.texi:
  - in the 'Options Summary' section, list the new '-O' before '-p'
  - replace "The end of of this paragraph" with "The end of this
paragraph"
- in variable.c:
  - replace "but the the rest of the chain" with "but the rest of the
chain"
- in readme.vms:
  - replace "That deletes the them" with "That deletes them"

Regards,

Denis Excoffier.



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make release candidate 3.99.90 available

2013-05-17 Thread Denis Excoffier 

On 2013-05-17 10:12, Paul Smith  wrote:

> Hi all.  The first release candidate for the next release of GNU make,
> GNU make 4.0, is now available for download:
> 
> http://alpha.gnu.org/gnu/make/make-3.99.90.tar.gz  
> 37c2d65196a233a8166d323f5173cdee
> http://alpha.gnu.org/gnu/make/make-3.99.90.tar.bz2 
> 40c0a62e1f4e0165d51bc4d7f93a023c
> 
> There are many bug fixes and new features.  Please see the NEWS file for
> full details.
> 
> http://git.savannah.gnu.org/cgit/make.git/tree/NEWS
> 
> Note I will be away this weekend and not reading email so please don't
> expect a response from me until next week.
> 
> Cheers, and happy making!
> 

Thanks. We were all very impatient i suppose...

Compared with make-3.82, the new make-3.99.90 breaks those Makefiles, like
in tiff-v3.6.1 (rather old i know, before 2003 at least), that use the 
construction:

make -${MAKEFLAGS}

Indeed, in case of "-j n", MAKEFLAGS does no longer includes a space at
its beginning, before the "--jobserver-fds...". Hence, make fails with
the message "Unrecognized option ---jobserver-fds=..." (note the three dashes).

Previously, it used to work, if not "as expected", but more or less yes, thanks
to the undocumented? target "-" that (still under the new make) does nothing at 
all:

% cat Makefile
default - --:; @echo "$@"
% make -
default
% make -- -
default
% make -- ./-
-
% make -- --
--
%


Perhaps something is worth noting in NEWS or in documentation?

Regards,

Denis Excoffier.



___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

make-3.82.91

2011-12-13 Thread Denis Excoffier 
Hello,

Could we please get in the near future (why not as a Christmas present?) an 
`official' make-3.82.91.tar.bz2 or equivalent on 
ftp://alpha.gnu.org/pub/gnu/make/ ?

Regards,

Denis Excoffier.

P.S. I say make-3.82.91 instead of make-3.82.90 because we have already this 
number on Cygwin, cut from CVS
on the 2nd of December.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make