On Sat, 2019-08-31 at 13:59 +0300, Eli Zaretskii wrote:
> The failures where all eyeballed, and the conclusion is that they are
> due to non-portable assumptions that are too much work to fix. The
> worst offenders are:
>
> . the assumption that $$FOO gets expanded by the shell into the
>
On Thu, 2019-09-05 at 02:17 -0400, Dennis Clarke wrote:
> > So, it is not useless to test building with all improvements turned off
> > because it lets us know whether our attempts to support very old
> > environments are still working properly.
> >
> > But I would not recommend using such
On 9/3/19 9:32 AM, Paul Smith wrote:
On Wed, 2019-08-28 at 17:35 -0400, Dennis Clarke wrote:
This also disables every extension over C, especially POSIX.
Is this a *bad* thing or a *good* thing ? What is the actual language
dialect that GNU Make wishes to be compliant with is the real
On Wed, 2019-08-28 at 17:35 -0400, Dennis Clarke wrote:
> > This also disables every extension over C, especially POSIX.
>
> Is this a *bad* thing or a *good* thing ? What is the actual language
> dialect that GNU Make wishes to be compliant with is the real question.
Like all GNU software, it
On Tue, 2019-09-03 at 10:25 +0200, Robert Pluim wrote:
> The good news is that this affects only building from git, the
> pre-release tarball builds fine with just './configure', and passes
> all but one test from 'make check'.
Yes, I do rely on GCC (and GNU make) when performing maintainer
> On Mon, 02 Sep 2019 12:28:52 -0400, Paul Smith said:
Paul> My first guess is that this another of a series of unpleasantnesses
Paul> caused by clang trying to "pretend" to be GCC, and failing.
Paul> I understand why the Clang devs do this: they want to take advantage
of
On Wed, 2019-08-28 at 14:01 +, Mike Gran wrote:
> The '--enable-load' configure option will cause warnings since
> --export-dynamic is not supported for PE+ targets.
I'm not sure what a PE+ target is, but as long as running configure
with no special flags correctly detects the situation and
On Mon, 2019-09-02 at 15:35 -0700, Paul Eggert wrote:
> We need to be portable to C99 and later. C89 and later if the
> programmer wants to and if it's not too much work. K C is almost
> surely not worth the effort.
I generally attempt to keep GNU make more portable than most GNU
projects as I
Dennis Clarke wrote:
I am wondering what is
the actual dialect to adher to.
We need to be portable to C99 and later. C89 and later if the programmer wants
to and if it's not too much work. K C is almost surely not worth the effort.
OpenSSL is a different project from OpenSSL and uses
On 9/2/19 4:12 PM, Paul Eggert wrote:
Dennis Clarke wrote:
On 9/2/19 12:28 PM, Paul Smith wrote:
On Mon, 2019-09-02 at 18:20 +0200, Robert Pluim wrote:
is this intended to build on macOS using clang, or using gcc only?
It should work with any C compiler that supports the C89 standard.
I
Dennis Clarke wrote:
On 9/2/19 12:28 PM, Paul Smith wrote:
On Mon, 2019-09-02 at 18:20 +0200, Robert Pluim wrote:
is this intended to build on macOS using clang, or using gcc only?
It should work with any C compiler that supports the C89 standard.
I was looking for this sort of answer
On 9/2/19 12:28 PM, Paul Smith wrote:
On Mon, 2019-09-02 at 18:20 +0200, Robert Pluim wrote:
is this intended to build on macOS using clang, or using gcc only?
It should work with any C compiler that supports the C89 standard.
I was looking for this sort of answer before. I have been
On Mon, 2019-09-02 at 18:20 +0200, Robert Pluim wrote:
> is this intended to build on macOS using clang, or using gcc only?
It should work with any C compiler that supports the C89 standard.
> $ gcc --version
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
>
> On Mon, 26 Aug 2019 09:00:13 -0400, Paul Smith said:
Paul>
Paul> GNU make is a tool which controls the generation of executables
and
Paul> other non-source files of a program from the program's
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sat, 31 Aug 2019 10:13:33 -0400
>
> Sorry, I'm away from home for the long US holiday. I expect to be able
> to do a bunch of work and possibly make another RC on Monday or so.
>
> The change you made below looks like it should work, but I
Sorry, I'm away from home for the long US holiday. I expect to be able
to do a bunch of work and possibly make another RC on Monday or so.
The change you made below looks like it should work, but I haven't had
a chance to try it. I really don't know why the extra /bin/sh is there
but I've
> Date: Wed, 28 Aug 2019 13:50:18 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> I'm not sure I should look into each and every failure, given that the
> test suit is clearly not meant to run on Windows. Not unless you have
> some magic way of making all these problems go away with some
Ping! Is it OK to push the change I propose below?
> Date: Wed, 28 Aug 2019 19:01:39 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Wed, 28 Aug 2019 11:25:25 -0400
> >
> >$string = `sh -c "$make_path -f null.mk $redir"`;
> >
On 8/28/19 5:08 AM, Andreas Schwab wrote:
On Aug 27 2019, Dennis Clarke wrote:
(1) -std=9899:1999This is the same as c99 and it merely means that
GCC *should* make every reasonable attempt to comply with the C99 code
specification.
This also disables every extension over C, especially
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 28 Aug 2019 11:25:25 -0400
>
>$string = `sh -c "$make_path -f null.mk $redir"`;
>if ($string =~ /(.*): \*\*\* No targets\. Stop\./) {
> $make_name = $1;
>}
>else {
> $make_path =~ /^(?:.*$pathsep)?(.+)$/;
>
On Wed, 2019-08-28 at 17:50 +0300, Eli Zaretskii wrote:
> It turns out MinGW does have 'umask', so I added HAVE_UMASK to
> config.h.W32.template under __MINGW32__. The no-op function is
> probably for MSVC? and maybe VMS?
It seems it exists for Visual Studio:
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 28 Aug 2019 09:55:14 -0400
>
> On Wed, 2019-08-28 at 16:25 +0300, Eli Zaretskii wrote:
> > > If they work that would be my preference, rather than adding
> > > another variable.
> >
> > Agreed. If you can test that, that'd be great.
>
> I
> Date: Wed, 28 Aug 2019 16:25:22 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > The rest of the changes look fine to me.
>
> OK, will push them soon.
Done.
___
Bug-make mailing list
Bug-make@gnu.org
> Date: Wed, 28 Aug 2019 16:36:23 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > Very likely it's because I have Git for Windows installed on my system.
>
> So do I, it just isn't on the Windows PATH.
>
> > I'm sure that make is finding the sh.exe that comes with that and
> > that's
> On Monday, August 26, 2019 06:00:57 AM PDT, Paul Smith
> wrote:
> A new release candidate for GNU make 4.3 is available now for download:
Hello all,
I tried it on a new 64-bit Cygwin, and it isn't too bad so far.
The '--enable-load' configure option will cause warnings
On Wed, 2019-08-28 at 16:25 +0300, Eli Zaretskii wrote:
> > If they work that would be my preference, rather than adding
> > another variable.
>
> Agreed. If you can test that, that'd be great.
I tried it and it worked with Visual Studio (to use forward-slashes in
the source file name).
> >
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 28 Aug 2019 07:44:53 -0400
>
> On Wed, 2019-08-28 at 13:50 +0300, Eli Zaretskii wrote:
> > I'm not sure I should look into each and every failure, given that the
> > test suit is clearly not meant to run on Windows. Not unless you have
> >
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 28 Aug 2019 07:41:33 -0400
>
> On Wed, 2019-08-28 at 12:29 +0300, Eli Zaretskii wrote:
> >This seems to be due to a subtle bug/misfeature in the GNU linker:
> >it doesn't grok backslashes in file names in response files. I
> >
On Wed, 2019-08-28 at 13:50 +0300, Eli Zaretskii wrote:
> I'm not sure I should look into each and every failure, given that the
> test suit is clearly not meant to run on Windows. Not unless you have
> some magic way of making all these problems go away with some setup...
Very likely it's
On Wed, 2019-08-28 at 12:29 +0300, Eli Zaretskii wrote:
>This seems to be due to a subtle bug/misfeature in the GNU linker:
>it doesn't grok backslashes in file names in response files. I
>needed to introduce a special variable to give each linker its
>preferred flavor of slashes.
There are also many test failures due to assumptions that are only
true on Posix hosts. For example, what is the output when several
commands are chained with ';', the fact that 'echo' builtin removes
quotes, the fact that $foo is expanded by the shell to the value of
'foo', etc.
I'm not sure I
> Date: Wed, 28 Aug 2019 12:18:13 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> "One or two"? I have 297 failures. Many of them due to exit status
> incompatibility, like this:
>
> features/include Error running
>
> From: Paul Smith
> Date: Mon, 26 Aug 2019 09:00:13 -0400
>
> A new release candidate for GNU make 4.3 is available now for download:
>
> 36083ab822b50a9ecbf5467cdadff55c make-4.2.90.tar.bz2
> e2c9abdeaf3725f8654a5e9d7a121fa9 make-4.2.90.tar.gz
Building this on MS-Windows using
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Mon, 26 Aug 2019 12:31:44 -0400
>
> I do it like this:
>
> cd tests
> .\run_make_tests.bat -make ..\WinRel\gnumake.exe
>
> so it runs the just-built make (else it will run whatever is on your
> PATH).
>
> IIRC there may be a failure or two
On Aug 27 2019, Dennis Clarke wrote:
> (1) -std=9899:1999This is the same as c99 and it merely means that
> GCC *should* make every reasonable attempt to comply with the C99 code
> specification.
This also disables every extension over C, especially POSIX.
Andreas.
--
Andreas Schwab,
On 8/27/19 1:46 PM, Paul Smith wrote:
Sorry, I didn't mean you needed to explain all these options to me :).
I was being overly Canadian and trying to apologize for weird things in
my setup and then trying to use "rubber ducky" debugging to explain to
myself why I was doing this.
In
Sorry, I didn't mean you needed to explain all these options to me :).
In particular I was wondering about the CPPFLAGS, because attempting to
add reserved preprocessor options to the compile line can cause
problems in system header files. Also, by adding a new include
directory to search, there
On 8/26/19 10:59 PM, Paul Smith wrote:
On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
I'll dig into this but on RHEL 7.4 x86_64 we see :
src/job.c: In function 'reap_children':
src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
EINTRLOOP (pid, wait
On 8/27/19 8:33 AM, Paul Smith wrote:
> On Tue, 2019-08-27 at 01:21 -0400, Dennis Clarke wrote:
>> On 8/26/19 10:59 PM, Paul Smith wrote:
>>> On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
I'll dig into this but on RHEL 7.4 x86_64 we see :
src/job.c: In function
On Tue, 2019-08-27 at 01:21 -0400, Dennis Clarke wrote:
> On 8/26/19 10:59 PM, Paul Smith wrote:
> > On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
> > > I'll dig into this but on RHEL 7.4 x86_64 we see :
> > >
> > > src/job.c: In function 'reap_children':
> > > src/job.c:754:17: error:
On Aug 26 2019, Paul Smith wrote:
> On Mon, 2019-08-26 at 10:26 -0700, David Boyce wrote:
>> Does this mean that the autotools config system will select
>> POSIX_SPAWN_USEVFORK? That's not a behavior of GNU make per se.
>
> Yes, autoconf will detect and use it. I'm not sure I understand the
>
On 8/26/19 10:59 PM, Paul Smith wrote:
On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
I'll dig into this but on RHEL 7.4 x86_64 we see :
src/job.c: In function 'reap_children':
src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
EINTRLOOP (pid, wait
On Mon, 2019-08-26 at 19:33 -0400, Dennis Clarke wrote:
> I'll dig into this but on RHEL 7.4 x86_64 we see :
>
> src/job.c: In function 'reap_children':
> src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
> EINTRLOOP (pid, wait ());
That is REALLY disturbing,
On 8/26/19 9:00 AM, Paul Smith wrote:
GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.
You can learn more at:
On Mon, 2019-08-26 at 15:31 -0400, Paul Smith wrote:
> On Mon, 2019-08-26 at 11:57 -0700, David Boyce wrote:
> > > I guess this is confusing ...
> >
> > There may be confusion in the text between "the number of jobs
> > running" and "the number of jobs running *on a core*".
>
> Well, there can
On Mon, 2019-08-26 at 11:57 -0700, David Boyce wrote:
> > I guess this is confusing ...
>
> There may be confusion in the text between "the number of jobs
> running" and "the number of jobs running *on a core*".
Well, there can only ever be one job running on core (at a time), by
definition; I
> I guess this is confusing ...
There may be confusion in the text between "the number of jobs running" and
"the number of jobs running *on a core*".
> If you use -lN -j, make can kick off enough jobs to kill your system
before the load average can change enough to throttle it.
Understood.
>
On Mon, 2019-08-26 at 10:26 -0700, David Boyce wrote:
> > the -l/--load-average option will use the contents of that file to
> determine how many jobs are running at any given instant, and compare
> that value to the load value requested.
>
> Compare and do what? This doesn't make sense to me.
I
Feedback on release notes - there are a couple of things unclear at least
to me:
> the -l/--load-average option will use the contents of that file to
determine how many jobs are running at any given instant, and compare that
value to the load value requested.
Compare and do what? This doesn't
On Mon, 2019-08-26 at 19:26 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > Date: Mon, 26 Aug 2019 09:00:13 -0400
> >
> > A new release candidate for GNU make 4.3 is available now for
> > download:
> >
> > 36083ab822b50a9ecbf5467cdadff55c make-4.2.90.tar.bz2
> >
> From: Paul Smith
> Date: Mon, 26 Aug 2019 09:00:13 -0400
>
> A new release candidate for GNU make 4.3 is available now for download:
>
> 36083ab822b50a9ecbf5467cdadff55c make-4.2.90.tar.bz2
> e2c9abdeaf3725f8654a5e9d7a121fa9 make-4.2.90.tar.gz
>
> You can obtain a copy from:
GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.
You can learn more at: https://www.gnu.org/software/make/
52 matches
Mail list logo
