Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

[Dennis Clarke via Bug reports and discussion for GNU make]

On 4/19/24 15:15, Paul Smith wrote:

On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote:

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith  wrote:

The main advantages to alloca are twofold:

1) efficiency for small local buffers, which GNU Make uses a lot.

2) simplification of the code because you don't have to track this
memory and ensure it's freed regardless of how the function
returns.


Dennis, do you see an alternative that is at least equally efficient,
simple and portable?  One alternative that is equally efficient and
simple is variable length arrays.  However, there is a question about
portability of vla vs alloca.


VLAs are strictly less powerful than alloca because alloca() is scoped
to the function, while VLAs are scoped to the enclosing block.  That is
a serious flaw in VLAs and means that it is impossible for them to
replace alloca() in many simple, obvious situations.

In addition, while alloca() is best implemented by the compiler it IS
possible to provide a standards-conforming implementation of them
(which is less performant than a compiler-provided alloca(), but which
works) which means that alloca() is more portable than VLAs, which will
cause compiler errors in any compiler that doesn't support them.

So, I have zero interest in VLAs.  In my opinion they were a mistake
from the first and should never have been implemented or standardized.
I did share this opinion and provided examples of how limiting and
limited they were back when they were being considered for
standardization but, well, it didn't matter.




Just a reply to let you know I am thinking on this.

Have been pondering it for quite a while and will likely give this
some real thought.

That means a lot more than just "cut and paste".

We surely agree in that regard.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

[Dennis Clarke via Bug reports and discussion for GNU make]

On 4/19/24 14:38, Dmitry Goncharov wrote:

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith  wrote:

The main advantages to alloca are twofold:

1) efficiency for small local buffers, which GNU Make uses a lot.

2) simplification of the code because you don't have to track this
memory and ensure it's freed regardless of how the function returns.


Dennis, do you see an alternative that is at least equally efficient,
simple and portable?
One alternative that is equally efficient and simple is variable length arrays.
However, there is a question about portability of vla vs alloca.

regards, Dmitry



It would take a pile of work and time to climb into the code and
replace all of the alloca() stuff with good ol' malloc/calloc. The work
required would be non-trivial and who knows ... may not be worth the
pain. It would be seriously cool if the code was strictly C99 compliant
but again ... gee ... the pile of work it would take and the testing
also. I do not want to just paint the bike shed here. Just a really non-
trivial task and I am currently pouring over floating point issues in
the BSD world as well as code compliance problems in OpenSSL. There is
no shortage of code work that can be done which would be of benefit but
I think the libC issues take precedence.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

[Dennis Clarke via Bug reports and discussion for GNU make]

On 4/19/24 10:27, Paul Smith wrote:

On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and
discussion for GNU make wrote:

Where does one even begin to discover where something ( everything? )
went so horribly wrong?


The very first thing you should try is re-configuring GNU Make without
any special flags (unset CFLAGS) and re-run configure from scratch and
see if that build works better.


Thank you for the quick reply.

Good idea. I figure that another approach would be to change just a few
things and give it a whirl ... with excellent results :

$ echo $CFLAGS
-m64 -g -O0 -march=k8 -mtune=k8 -fomit-frame-pointer -fstrict-aliasing 
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags

$

.
.  a cup of coffee later
.

1442 Tests in 134 Categories Complete ... No Failures :-)


===
 Regression PASSED: GNU Make 4.4.1 (x86_64-unknown-netbsd10.0) built 
with /usr/bin/gcc

===

Neato.



As far as I can tell the problem is because you're including this:

   -fno-builtin




Yep. The calls to alloca() seem to be all over the place in the code
base and I can not figure out why anyone would want a non-portable and
non-standard thing like that but here we are.



in your CFLAGS.  I'm not sure why you want to do that, but I recommend
removing that, at least.  I don't actually know exactly why that causes
a problem but it's completely clear from the test results that the
problems you're having are due to bad memory which means I agree with
you it's due to this alloca mismatch/issue.  I can't say why the
problem happens: either GCC's handling of -fno-builtin has an issue or
else the configure script's detecting of the situation is not working
correctly.



There are a number of reasons to disable the GCC compilers dirty little
tricks where it will replace things like "printf" with "puts".  At the
very least it is really tough to explain to a student trying to debug
some trivial code when they see strange things appear in the assembly
when the post processed intermediate code calls for a "printf". So I
have had great success with the -fno-builtin option in many many places.
That includes the libgmp and libmpfr codebase.

So now I will go digging around and see why alloca() is being used all
over the GNU Make code. There must be a valid reason for that stuff. I
can tell you the manpage for ALLOCA(3) on NetBSD is just nasty :

io# man alloca
man: Formatting manual page...
ALLOCA(3)   Library Functions Manual   ALLOCA(3)

NAME
 alloca – memory allocator

LIBRARY
 Standard C Library (libc, -lc)

SYNOPSIS
 #include 

 void *
 alloca(size_t size);

DESCRIPTION
 The alloca() function allocates size bytes of space in the stack
 frame of the caller.  This temporary space is automatically freed
 on return.

RETURN VALUES
 The alloca() function returns a pointer to the beginning of the
 allocated space.  If the allocation failed, a NULL pointer is
 returned.

SEE ALSO
 cc(1), brk(2), calloc(3), getpagesize(3), malloc(3), realloc(3),
 security(7)

CAVEATS
 Few limitations can be mentioned:

 •   The alloca() function is not part of any C standard and its use
 is not portable.

 •   The alloca() function should be supplied by the compiler
 because the compiler is allowed to make assumptions about the
 stack and frame pointers.  The libc alloca() implementation
 cannot account for those assumptions.  While there is a machine
 dependent implementation of alloca() in libc, its use is
 discouraged and in most cases it will not work.  Using this
 implementation will produce linker warnings.

 •   The alloca() function is unsafe because it cannot ensure that
 the pointer returned points to a valid and usable block of
 memory.  The allocation made may exceed the bounds of the
 stack, or even go further into other objects in memory, and
 alloca() cannot determine such an error.  For that all alloca()
 allocations should be bounded and limited to a small size.

 •   Since alloca() modifies the stack at runtime and the stack
 usage of each function frame cannot be predicted, it makes many
 compiler security features (such as cc(1) -fstack-protector)
 useless for the calling function.  See security(7) for a
 discussion.

NetBSD 10.0 October 24, 2012 NetBSD 10.0

Yep.  Those warnings in the "CAVEATS" section are pretty scary. Really a
convenient way to toss malloc/calloc over one's shoulders and just give
up on tracking what was allocated on the heap. Convenient. Ugly.

I will mess around further with some compiler options but for now the
thing compiles and tests clean

TESTs fail features/output-sync and features/parallelism on Linux 4.4.194 armv7l

[Dennis Clarke via Bug reports and discussion for GNU make]

 (2 passed)
variables/SHELL . ok (8 passed)
variables/automatic . ok (9 passed)
variables/define  ok (17 passed)
variables/flavors ... ok (15 passed)
variables/negative .. ok (7 passed)
variables/private ... ok (16 passed)
variables/special ... ok (3 passed)
variables/undefine .. ok (5 passed)
vms/library . N/A

2 Tests in 2 Categories Failed (See .diff* files in work dir for 
details) :-(


*** Testing FAILED!  Details: 
makeerror-4.4.1-armv7l-unknown-linux-gnueabihf-izkr.tar.gz

*** Please report to 

make[2]: *** [Makefile:1551: check-regression] Error 1
make[2]: Leaving directory '/opt/bw/build/make-4.4.1_debian_10_armv7l.001'
make[1]: *** [Makefile:1284: check-am] Error 2
make[1]: Leaving directory '/opt/bw/build/make-4.4.1_debian_10_armv7l.001'
make: *** [Makefile:986: check-recursive] Error 1
io$


Configure was trivial :

  $ ./configure --prefix=/opt/bw


Most other tools are very up to date here :


io$
io$ $CC --version
gcc (GENUNIX Tue Dec  5 01:57:08 UTC 2023) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

io$
io$ $AS --version
GNU assembler (GNU Binutils) 2.42
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of 
`armv7l-unknown-linux-gnueabihf'.

io$





--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

make-4.3 on Linux x86_64 fails features/output-sync test

[Dennis Clarke via Bug reports and discussion for GNU make]

This is highly unexpected on a plain jane Linux x86_64 type box :

--
   Running tests for GNU make on Linux esther 6.1.63-genunix x86_64
 GNU Make 4.3
--

Finding tests...

features/archives ... ok (12 passed)
features/comments ... ok (1 passed)
.
.
.
features/order_only . ok (10 passed)
features/output-sync  Error running 
/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make (expected 
0; got 512): 
/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make -f 
work/features/output-sync.mk -j -Orecurse

FAILED (14/15 passed)
features/override ... ok (4 passed)
.
.
.

e#
e# find . -type f | grep '\.diff$'
./tests/work/features/output-sync.diff
e#
e# wc -l ./tests/work/features/output-sync.diff
34 ./tests/work/features/output-sync.diff
e#
e# cat ./tests/work/features/output-sync.diff
*** work/features/output-sync.base  Mon Nov 27 20:22:18 2023
--- work/features/output-sync.log   Mon Nov 27 20:22:18 2023
***
*** 1,12 
  /opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make -C foo
  make[1]: Entering directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/foo'

  foo: start
! foo: end
  make[1]: Leaving directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/foo'

  /opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make -C bar
  make[1]: Entering directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/bar'

  bar: start
  bar: end
  baz: start
! baz: end
  make[1]: Leaving directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/bar'

--- 1,17 
  /opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make -C foo
  make[1]: Entering directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/foo'

  foo: start
! wait ../mksync.bar: timeout after 4 seconds
! make[1]: *** [Makefile:7: foo-base] Error 2
  make[1]: Leaving directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/foo'

+ make: *** [work/features/output-sync.mk:4: make-foo] Error 2
+ make: *** Waiting for unfinished jobs
  /opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/../make -C bar
  make[1]: Entering directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/bar'

  bar: start
  bar: end
  baz: start
! wait ../mksync.foo: timeout after 4 seconds
! make[1]: *** [Makefile:19: baz-base] Error 2
  make[1]: Leaving directory 
'/opt/bw/build/make-4.3_linux_pentium_G4500.001/tests/bar'

+ make: *** [work/features/output-sync.mk:6: make-bar] Error 2
e#

Well I have no idea what to make of that.



--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: oddball messages on FreeBSD that cause make to fail the testsuite

[Dennis Clarke]

On 2/15/22 00:38, Paul Smith wrote:

On Mon, 2022-02-14 at 18:54 -0500, Dennis Clarke wrote:

variable 'plugin_is_GPL_compatible' [-Wmissing-variable-declarations]


This is happening because you're adding extra compile-time options to
the standard GNU make build, and those options are getting passed
through to the test suite.

Most likely we should expend a little effort to sanitize the options
provided to the compiler in the test suite to remove unneeded things
like extra warnings.

However, in general when compiling external tools it's probably not a
good idea to force extra warning flags etc. into the build, unless
you're actually trying to develop or debug the code.  If you're just
trying to build it to use it, then adding extended warnings usually
just generates spurious issues.



Yep. I figured as much. I changed the CFLAGS to :

bw$
bw$ echo $CFLAGS
-std=iso9899:2011 -m64 -g -O0 -fno-fast-math -fno-builtin 
-Wl,-rpath=/opt/bw/lib

bw$

Then everything "just works".

However building and trying to test with -Weverything and a few other
noisey LLVM/Clang options does really toss a massive amount of bitter
complaints about, well as the Woption says, everything.  Even the colour
of your walls and why does you cat walk that way?  It will even spit
in your coffee when you are not looking. Not helpful but it is
interesting that the compile still works fine. Testsuite? Not so much.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

oddball messages on FreeBSD that cause make to fail the testsuite

[Dennis Clarke]

I was really surprised to see this on amd64 FreeBSD 13.0 :


2 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

*** Error code 1

Stop.
make[2]: stopped in /opt/bw/build/make-4.3_fbsd13_amd64.001
*** Error code 1

Stop.
make[1]: stopped in /opt/bw/build/make-4.3_fbsd13_amd64.001
*** Error code 1

Stop.
make: stopped in /opt/bw/build/make-4.3_fbsd13_amd64.001


The diff files seem to be all about a compiler warning :

bw$
bw$ cat  ./tests/work/features/load.diff.3
*** work/features/load.base.3   Mon Feb 14 16:48:38 2022
--- work/features/load.log.3Mon Feb 14 16:48:38 2022
***
*** 1,2 
--- 1,9 
  rebuilding testload.so
+ testload.c:6:5: warning: no previous extern declaration for non-static 
variable 'plugin_is_GPL_compatible' [-Wmissing-variable-declarations]

+ int plugin_is_GPL_compatible;
+ ^
+ testload.c:6:1: note: declare 'static' if the variable is not intended 
to be used outside of this translation unit

+ int plugin_is_GPL_compatible;
+ ^
+ 1 warning generated.
  pre= post=testload.so implicit
bw$
bw$
bw$ cat  ./tests/work/features/load.diff.4
*** work/features/load.base.4   Mon Feb 14 16:48:38 2022
--- work/features/load.log.4Mon Feb 14 16:48:38 2022
***
*** 1,2 
--- 1,9 
  rebuilding testload.so
+ testload.c:6:5: warning: no previous extern declaration for non-static 
variable 'plugin_is_GPL_compatible' [-Wmissing-variable-declarations]

+ int plugin_is_GPL_compatible;
+ ^
+ testload.c:6:1: note: declare 'static' if the variable is not intended 
to be used outside of this translation unit

+ int plugin_is_GPL_compatible;
+ ^
+ 1 warning generated.
  pre= post=testload.so explicit
bw$


I went looking for this "testload" thingy and could not find it.
Any ideas ?




--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: Missing INSTALL instructions for GNU make 4.3

[Dennis Clarke]

On 2020-04-29 16:58, Gleb Satyukov wrote:

Hi team,

The latest version of GNU make (4.3) does not contain the INSTALL instructions 
as references in the README.

Thanks,
Gleb



Doesn't everyone just "make install" ?

Sort of causes one to wonder about the chicken and egg scenario
of a machine which has no previous "make" anywhere.  That would be
interesting. Probably have to fall back on pure scripts.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: GNU make 4.2.93 release candidate available

[Dennis Clarke via Bug reports and discussion for GNU make]

On 2020-01-11 13:22, Martin Dorey wrote:
>> accept prerequisites and implement them as
> the user expects, which violates POSIX ... and which never happened
> before
>
> I fear implementing what the makefile author asked for instead of
> what they got... could expose other latent issues in their makefile.
>
>> Martin had suggested some kind of warning
>
> I’m glad Paul remembers because I struggled to find
> https://savannah.gnu.org/bugs/?40657 before recalling it.
>  That let me find the makefiles I’d had to fix.
.
.
.
>
> Still, I favor a third option: restoring the previous, accidental
> behavior - treating the rule as a suffix rule with no prerequisites
> - but generating a warning about it.  Paul rightly prefers the
> posix-mandated behavior but it’s not like anyone’s really agitating
> for the posix behavior on such obscure filenames, right?
> Keeping the new, correct behavior in the .POSIX case, with no
> warning, that might fly, as long as none of Dennis’s myriad failing
> builds use .POSIX.  I can imagine Paul finding this third option
> depressing but I think the real value here is in telling the
> maintainer that their makefile is broken rather than in fixing a
> posix conformance corner case that no one ever noticed.

I would like to make the suggestion here that it is entirely reasonable
after a four year release stretch to build in a warning. Such a trivial
warning would give people time to fix the error of their Makefile ways
while also allowing for the world to keep on building software. At the
very least it shows the software maintainers that there are to be no
sudden surprises when the next release of GNU Make comes along and it
will actually enforce the correct behavior.  My hope is that the time
to that next release is at least six months.  What say you all to such
a compromise?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: GNU make 4.2.93 release candidate available

[Dennis Clarke]

On 2020-01-10 14:54, Paul Smith wrote:

On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:

Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
a whole slew of packages fail to build.


I can reproduce these failures trying to build dpkg 1.19.7 on GNU/Linux
with the new make.  Ugh!!

There seems to be some issue with old-style suffix rules.

I will investigate this tonight.  Thanks for noticing this!



Just the sort of thing we do. I really do love the test suite in gnu
make but nothing beats the coffee pot draining horror show of trying to
build thirty thousand packages from source on FreeBSD. That can really
shake loose the most tiny corner cases. As for Solaris 10 on ye old
Fujitsu SPARC and the Oracle studio compilers, well gee, I just use that
to shake loose some obsessive compusive standards compliance stuff.
Which it does. Wonderfully and at great endless cost. Gotta love Oracle.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: GNU make 4.2.93 release candidate available

[Dennis Clarke]

On 2020-01-07 20:39, Paul Smith wrote:

On Mon, 2020-01-06 at 05:33 -0500, Dennis Clarke wrote:

The only nit, and it is a little nit, is the strange use of a three
parameter main() in src/main.c line 1054 and this is a "warning". Well
strictly speaking, pun intended, that isn't a terrible sin but it isn't
correct either. Sure, tossing in char **envp as the third rail on the
main() can work and usually does work it isn't supposed to work.

I looked in there and there is no good reason to not use getenv() but
who knows what voodoo to do in windows32?  I surely don't.


Just for clarity, getenv() isn't sufficient.  That requires that you know
what variables you want to look up: in GNU make we need to walk through all
the variables so we can import each one as a make variable.

In POSIX we can use extern char** environ instead.  On Windows you can use
_environ although my impression is that might not work everywhere (but it
might be good enough for make).  On other systems there may be other
things.

While the third arg to main isn't actually part of any standard, even
POSIX, it's actually very widely supported.



Yep. Wrong and it seems to work anyways.

I was slightly surprised to get this latest alpha gmake 4.2.93 to
compile clean and test perfectly on old Solaris 10.  I keep around that
sort of hardware for production reasons and they are all legacy now. One
thing is true however and that is the OS is tightly standards compliant
and that includes the Oracle/Sun Studio 12.6 C99 compiler with obsessive
compulsive compliance flags. I nearly spit out my coffee. Clean. Every
damn line with the exception of a tiny little warning about "hey there
please don't use a third parameter to main(), thanks".


See ISO/IEC 9899:TC3 WG14/N1256 bloody C99 specifications section 
5.1.2.2.1 Program Startup :


The function called at program startup is named main. The
implementation declares no prototype for this function. It shall
be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though
any names may be used, as they are local to the function in which
they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; 9) or in some other implementation-defined manner.

Right. However gmake tries int argc, char **argv, char **envp in
src/main.c at line 1054 and I am trying to care. I don't really.

For some reason you say GNU make needs to read in the entire users
environment? Really? OKay ... *shrug* ...

Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
a whole slew of packages fail to build. We don't know why yet :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243145

Feels like progress to me regardless. I will stay in touch as I drag
this over multiple systems and architectures.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: GNU make 4.2.93 release candidate available

[Dennis Clarke]

On 2020-01-05 16:20, Paul Smith wrote:

On Fri, 2020-01-03 at 02:42 -0500, Paul Smith wrote:

A new release candidate for GNU make 4.3 is available now for download:

 6b252188079b36d13e96d5527f8ca033  make-4.2.93.tar.lz
 929d4d3a216c02d0d86eb379356f4d1c  make-4.2.93.tar.gz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/


Unless something drastic changes this will be the final release candidate
for GNU make 4.3 and I plan to make the official release sometime this
week, perhaps Wednesday or Thursday.

If you want to test before the 4.3 release, please do so in the next few
days.  Or if there's a problem let me know.




Works neatly on ye old Solaris 10 sparcv9 with the Oracle C99 12.6 
compiler and insanely strict CFLAGS. Even tossed in POSIXLY_CORRECT=1

at this.

The only nit, and it is a little nit, is the strange use of a three
parameter main() in src/main.c line 1054 and this is a "warning". Well
strictly speaking, pun intended, that isn't a terrible sin but it isn't
correct either. Sure, tossing in char **envp as the third rail on the
main() can work and usually does work it isn't supposed to work.

I looked in there and there is no good reason to not use getenv() but
who knows what voodoo to do in windows32?  I surely don't.

Looks like a good release after all these tests and years. Awesome.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: [bug #57014] make-4.2.91 segfaults under Solaris 10 when many files are involved

[Dennis Clarke]

On 2019-10-07 15:33, Paul Smith wrote:

On Mon, 2019-10-07 at 11:26 -0400, Dmitry Goncharov wrote:

On Mon, Oct 7, 2019 at 9:03 AM anonymous 
wrote:

With the following Makefile, make-4.2.91 segfaults on my Solaris
10:


...

include /dev/null
dummy: subdir/*.c
include /dev/null


This reproduces for me. This is the same read past the end of the
string inside sum_up_to_nul that is already fixed in git.
Denis, can you please pull the latest, built, run and report?


Unfortunately it's not easy to build from Git unless you have a full
suite of autotools available.


Indeed this is true but having all those tools is mostly just a set of
steps and some effort.  Therefore let's not think of automake/autoconf
and friends as a barrier whatsoever.


I am thinking of creating the official 4.3 release any day now (I was
going to do it yesterday but got sidetracked).  I can instead create a
new release candidate if people feel it's warranted.


Yes please.  With full enthusiasm.


I've often wished there was a straightforward way to generate "nightly
builds" (at least for nights when there have been changes pushed) that
we could point people at.

I have no problems making them, I just am not sure where to publish
them.  Pushing them to alpha.gnu.org is a lot of overhead but maybe
that's the right place anyway.


Firstly, this needs to be said. Thank you for your efforts and endless
diligence.  In my opinion GNU make is the beginning of all things to be
built on just about any system that is able.  It has become the defacto
standard 'make' and that has been true for at least a decade. Let's not
rush headlong without a great deal of care. Another release candidate is
a great idea. Consider that GNU Make 4.2.1 has done well for a long time
now and whatever release we work towards today will become the baseline
starting point of toolchains everywhere. We should take time and care.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional


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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 question.


Like all GNU software, it is written to work with a minimum version but
uses autoconf facilities to take advantage of the newest capabilities
it can detect... that's kind of autoconf's raison d'être.

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 options when trying to compile an
actual, useful GNU make for everyday use, as it will be full of
workarounds and hacks and won't take advantage of modern POSIX features
which give better behavior and performance.


Well I have older systems to run and work with and so the software needs
to work there. Period.  Unless some statement is made that says "GNU
Make will no longer be supported on these platforms ..." which is the
approach that the GCC folks take.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 was looking for this sort of answer before.  I have been doing testing
with std=iso9899:1999 and so that is wrong.


Say what? I'm sure GNU Make is also designed to work with C99, with C11, 
with C18, and with C2x whenever it comes out.


I ran into this problem with the pre-release OpenSSL 1.1.1 code last[1]
year wherein I was doing testing with strict iso9899:1999 and found out
from Rich Salz that the codebase is strictly C89 only.  Given the range
of systems the OpenSSL project has to support I understand that. Here
with GNU Make we may face the same problem and so I am wondering what is
the actual dialect to adher to.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

[1] https://github.com/openssl/openssl/issues/8048

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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 doing testing
with std=iso9899:1999 and so that is wrong. Good to know. I think that
Paul Eggert was doing the same.

Dennis


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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 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.

Also ... really ?

On the Solaris 10 machines I think that both my self and Paul Eggert are
running the C99 compiler from Oracle Studio 12.6 with the -Xc flag :

The default mode of the compiler is -std=c11 without
the -pedantic flag.

-Xc (c = conformance) Issues errors and warnings for programs
that use non-ISO C constructs. This option is strictly
conformant ISO C without K C compatibility extensions.

https://docs.oracle.com/cd/E77782_01/html/E77788/bjapr.html#OSSCGbjask

However in the GCC world with anything flavour recent I see :

By default, GCC provides some extensions to the C language
that, on rare occasions conflict with the C standard.

See Extensions to the C Language Family. Some features that
are part of the C99 standard are accepted as extensions in C90
mode, and some features that are part of the C11 standard
are accepted as extensions in C90 and C99 modes. Use of
the -std options listed above disables these extensions where
they conflict with the C standard version selected.

Also :

A new edition of the ISO C standard was published in 1999 as
ISO/IEC 9899:1999, and is commonly known as C99. (While in
development, drafts of this standard version were referred to
as C9X.) GCC has substantially complete support for this
standard version; see http://gcc.gnu.org/c99status.html for
details.

To select this standard, use -std=c99 or -std=iso9899:1999.


Well now I feel sick to my stomach for doing that but I already had
explained ( with apologies ) to Paul Smith and the context of the
whole discussion was to just toss out on the table this is what I
am doing, have been doing for years and maybe should keep on doing
but if this looks icky and wrong then let's discuss it :

https://lists.gnu.org/archive/html/bug-make/2019-08/msg00071.html

The nice thing at my age is that I am so very fine with being wrong
and I was just going with the idea that we are working with some very
clear C flavour and I needed to know where we stand on linux boxen
and on FreeBSD ( with LLVM/Clang or GCC ) and on Solaris UNIX and on
some embedded FreeScale chip somewhere or RISC-V or whatever.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: more GNU make 4.2.90 issues on Solaris 10

[Dennis Clarke]

On 8/27/19 4:55 PM, Paul Eggert wrote:

Paul Smith wrote:

One problem seems to be that some tests assume that 'make check' runs 
GNU Make instead of /usr/ccs/bin/make, which chatters less.


Dear Paul :

I am using your patches plus two of my own and GNU Make 4.2.1 that I
just built and tested here.  I also --disable-posix-spawn thus :


beta$ pwd
/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003
beta$
beta$ dn
20190827225058
beta$
beta$ ./configure --prefix=/opt/bw --program-prefix=g \
> --disable-silent-rules --enable-dependency-tracking \
> --disable-posix-spawn --without-gnu-ld \
> --without-libiconv-prefix --without-libintl-prefix

This results in a very clean looking configure and a very quite and
clean compile with these CFLAGS :

beta$
beta$ echo $CC
/opt/developerstudio12.6/bin/c99
beta$
beta$ echo $CFLAGS
-Xc -g -errfmt=error -erroff=%none -xmemalign=8s -errshort=full 
-xstrconst -xildoff -m64 -xnolibmil -xcode=pic32 -xregs=no%appl 
-xlibmieee -ftrap=%none -xarch=sparc -mc -xs -xbuiltin=%none 
-xdebugformat=dwarf -xunroll=1

beta$

Test results are :

beta$ dn
20190827225603
beta$ /usr/bin/time -p /opt/bw/bin/gmake check
Making check in lib
gmake[1]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'

/opt/bw/bin/gmake  check-recursive
gmake[2]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'
gmake[3]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'

gmake[3]: Nothing to be done for 'check-am'.
gmake[3]: Leaving directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'
gmake[2]: Leaving directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/lib'

Making check in po
gmake[1]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/po'

gmake[1]: Nothing to be done for 'check'.
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/po'

Making check in doc
gmake[1]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/doc'

gmake[1]: Nothing to be done for 'check'.
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003/doc'
gmake[1]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003'

/opt/bw/bin/gmake  check-local
gmake[2]: Entering directory 
'/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003'
cd tests && /usr/local/bin/perl ./run_make_tests.pl -srcdir 
/opt/bw/build/make-4.2.90_SunOS5.10_sparc64vii+.003 -make ../make

--
 Running tests for GNU make on SunOS beta 5.10 sun4u
   GNU Make 4.2.90
--

Finding tests...

features/archives ... FAILED (11/12 
passed)

features/comments ... ok (1 passed)
features/conditionals ... ok (5 passed)
features/default_names .. ok (3 passed)
features/double_colon ... ok (14 passed)
features/echoing  ok (4 passed)
features/errors . ok (7 passed)
features/escape . ok (10 passed)
features/export . ok (12 passed)
features/grouped_targets  FAILED (11/12 
passed)

features/include  ok (19 passed)
features/jobserver .. ok (6 passed)
features/load ... FAILED (3/5 
passed)

features/loadapi  ok (3 passed)
features/mult_rules . ok (2 passed)
features/mult_targets ... ok (2 passed)
features/order_only . ok (10 passed)
features/output-sync  ok (15 passed)
features/override ... ok (4 passed)
features/parallelism  ok (13 passed)
features/patspecific_vars ... ok (10 passed)
features/patternrules ... ok (11 passed)
features/quoting  ok (1 passed)
features/recursion .. ok (3 passed)
features/reinvoke ... ok (5 passed)
features/rule_glob .. ok (3 passed)
features/se_explicit  ok (12 passed)
features/se_implicit 

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 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 could be files in that include directory
which overlap with/conflict with headers that are expected by make
and/or the operating system.


I tossed out the CPPFLAGS entirely.

Also the entire directory structure /opt/bw is empty other than the
build stuff and the src stuff. Well it *was* empty as I re-built make
version 4.2.1 and installed it into /opt/bw/bin as gmake.  I does
pass the testsuite.



In my work doing system/embedded/cross-compilation systems I've seen
MANY cases where these sorts of options cause strange and unexpected
behavior.



A good reason for me to toss them.  For now.



Note, make is not multithreaded so options that manage pthread etc. are
not relevant to it (but shouldn't hurt either).

If the /opt/dw directory is empty then clearly that's not a problem.



Shouldn't be.



Given that we're seeing a lot of strange and unexpected behavior I just
thought it might be helpful to remove all the customizations and start
with a "clean slate" to get a baseline.




   * agree *   which is why I went to /opt/bw or /opt/foo or whatever.


If you're confident that's not necessary, that's fine too.


  > If it chooses the one that comes with GNU make, you will see the error
  > (!!) because our glob/fnmatch is too old. >

How do we force the usage of the system version ?


I'm not sure there's any way to do that... well, you can pre-seed the
config cache but it's gross.  But, all the GNU/Linux ones I looked at
seemed to be using the system libc anyway so I don't think it's an
issue.



Well today has been better with both Debian stable x86_64 passing all
tests and now Debian sid on i686 32-bit as well.  I am using the patches
from Paul Eggert and trying again on Solaris 10 sparc.

Not sure if I am helping here or just spinning cycles but at the very
least I have an assortment of hardware and OS types on hand to do the
testing with.

Dennis

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

make 4.2.1 does build on Solaris 10 with Oracle Studio 12.6 C99

[Dennis Clarke]

ests for GNU make on SunOS beta 5.10 sun4u
GNU Make 4.2.1
--

Finding tests...

features/archives ... ok (10 passed)
features/comments ... ok (1 passed)
.
.
.
functions/guile . N/A
.
.
.
misc/close_stdout ... FAILED (no 
tests found!)

.
.
.
vms/library . N/A

582 Tests in 119 Categories Complete ... No Failures :-)

The system uptime program believes the load average to be:
uptime
 10:03pm  up 18 day(s),  5:11,  3 users,  load average: 0.22, 0.17, 0.14
The GNU load average checking code thinks:
./loadavg
1-minute: 0.222656  5-minute: 0.167969  15-minute: 0.140625

===
 Regression PASSED: GNU Make 4.2.1 (sparc-sun-solaris2.10) built with 
/opt/developerstudio12.6/bin/c99

===

gmake[2]: Leaving directory 
'/opt/bw/build/make-4.2.1_SunOS5.10_sparc64vii+.002'
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.1_SunOS5.10_sparc64vii+.002'




I will use this GNU make to work on make 4.2.90 going forwards.




--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: more GNU make 4.2.90 issues on Solaris 10

[Dennis Clarke]

Me either, that's super strange.

Does anyone remember if GNU make 4.2.1's output-sync tests failed this
way?
I grabbed 4.2.1 and tried it. Those tests fail similarly, so this is not 
a regression. Logs for 4.2.1 attached as well.




Hold on a moment. I have 4.2.1 building and passing all tests on
Solaris 10 with Oracle Studio 12.6.  Well it *claims* that all tests
pass :


--
Running tests for GNU make on SunOS node000 5.10 sun4u
GNU Make 4.2.1
--

Finding tests...

features/archives ... ok (10 passed)
features/comments ... ok (1 passed)
features/conditionals ... ok (5 passed)
features/default_names .. ok (3 passed)
features/double_colon ... ok (14 passed)
features/echoing  ok (4 passed)
features/errors . ok (3 passed)
features/escape . ok (8 passed)
features/export . ok (12 passed)
features/include  ok (15 passed)
features/jobserver .. ok (6 passed)
features/load ... ok (5 passed)
features/loadapi  ok (3 passed)
features/mult_rules . ok (2 passed)
features/mult_targets ... ok (2 passed)
features/order_only . ok (10 passed)
features/output-sync  ok (15 passed)
features/override ... ok (4 passed)
features/parallelism  ok (9 passed)
features/patspecific_vars ... ok (10 passed)
features/patternrules ... ok (10 passed)
features/quoting  ok (1 passed)
features/recursion .. ok (2 passed)
features/reinvoke ... ok (5 passed)
features/rule_glob .. ok (3 passed)
features/se_explicit  ok (10 passed)
features/se_implicit  ok (11 passed)
features/se_statpat . ok (4 passed)
features/shell_assignment ... ok (4 passed)
features/statipattrules . ok (8 passed)
features/targetvars . ok (25 passed)
features/utf8 ... ok (1 passed)
features/varnesting . ok (2 passed)
features/vpath .. ok (2 passed)
features/vpath2 . ok (1 passed)
features/vpath3 . ok (1 passed)
features/vpathgpath . ok (1 passed)
features/vpathplus .. ok (4 passed)
functions/abspath ... ok (1 passed)
functions/addprefix . ok (1 passed)
functions/addsuffix . ok (2 passed)
functions/andor . ok (2 passed)
functions/basename .. ok (1 passed)
functions/call .. ok (3 passed)
functions/dir ... ok (1 passed)
functions/error . ok (5 passed)
functions/eval .. ok (9 passed)
functions/file .. ok (15 passed)
functions/filter-out  ok (5 passed)
functions/findstring  ok (1 passed)
functions/flavor  ok (1 passed)
functions/foreach ... ok (6 passed)
functions/guile . N/A
functions/if  ok (1 passed)
functions/join .. ok (1 passed)
functions/notdir  ok (1 passed)
functions/origin  ok (1 

Re: patch to clean up lib/glob.c which may only help readability

[Dennis Clarke]

Sorry src/getopt.c was the major eye strain that I fixed there.

Dennis


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

patch to clean up lib/glob.c which may only help readability

[Dennis Clarke]

argv[optind - 1]);
! }
!
! nextchar += strlen (nextchar);
! return optstring[0] == ':' ? ':' : '?';
! }
! }
!
! nextchar += strlen (nextchar);
!
! if (longind != NULL)
! *longind = option_index;
!
! if (pfound->flag) {
! *(pfound->flag) = pfound->val;
! return 0;
! }
!
! return pfound->val;
!
! }
!
! nextchar = NULL;
! return 'W';/* Let the application handle it.   */
!
! }
!
! if (temp[1] == ':') {
! if (temp[2] == ':') {
!
! /* This is an option that accepts an argument 
optionally.  */

! if (*nextchar != '\0') {
! optarg = nextchar;
! optind++;
! } else {
! optarg = NULL;
! }
!
! nextchar = NULL;
!
! } else {
! /* This is an option that requires an argument.  */
! if (*nextchar != '\0') {
!
! optarg = nextchar;
! /* If we end this ARGV-element by taking the rest as
!  * an arg, we must advance to the next element 
now.  */

! optind++;
!
! } else if (optind == argc) {
!
!         if (opterr) {
! /* 1003.2 specifies the format of this 
message.  */

! fprintf (stderr,
! _("%s: option requires an argument -- %c\n"),
! argv[0], c);
! }
!
! optopt = c;
!
! if (optstring[0] == ':') {
! c = ':';
! } else {
! c = '?';
! }
!
! } else {
! /* We already incremented `optind' once  so here we
!  * increment it again when taking next ARGV-elt
!  * as argument.  */
! optarg = argv[optind++];
! }
!
! nextchar = NULL;
!
! }
!
! }
!
! return c;
!
! }
  }

  int


I tested on various systems and made no impact on tests failing or not.
Then again that is the whole struggle.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: [PATCH] Pacify Oracle Studio c99

[Dennis Clarke]

On 8/27/19 4:23 PM, Paul Eggert wrote:

Paul Smith wrote:

I saw this warning on Windows as well.  I seem to recall that this was
done on purpose to pack data structures more tightly, which can save a
lot of memory on large build systems.

However looking at it now I don't think it will actually end up saving
any space.


I don't either. In a struct, 'unsigned int foo : 8;' should behave like 
'unsigned short foo : 8;', and similarly if you change 'short' to 
'char', or change '8' to '1'. At least, that should be true for typical 
compilers (the C standard doesn't say exactly what should happen).




Could this be a good time to point to stdint.h and uintX_t for X bits?
May clarify matters.  However that leads to another funny question.
I have been running configure over and over on various machines with c99
type CFLAGS and also without them. One thing I do see is configure seems
to be happy about "checking for good max_align_t" where we get a no for
C99 and a yes if I specify no language standard at all. Well max_align_t
is a C11 type of concept and seems to have no bearing on the build or
tests running regardless.

So I have to ask is GNU Make shooting for C89 or C99 type dialect ?


Dennis

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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 ());


That is REALLY disturbing, because it means that configure couldn't
detect either waitpid() or wait3(), both of which have been available
since approximately forever.  Something went badly wrong with the
configure run on this system.



I re-tried on RHEL 7.4 with no CFLAGS and in fact a very stripped down
trivial environment.  I did not even specify where CC was.

The configure output was the same as yesterday and the compile did
complete.  How strange is that? The testsuite shows a multitude of
failures in various ways.

boe13$ ./configure --prefix=/opt/bw --program-prefix=g \
> --disable-silent-rules --enable-dependency-tracking \
> --with-gnu-ld --without-libiconv-prefix \
> --without-libintl-prefix
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports the include directive... yes (GNU style)
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 dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/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 minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for Minix Amsterdam compiler... no
checking for ar... ar
checking for ranlib... ranlib
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for complete errno.h... yes
checking for sys/param.h... yes
checking for unistd.h... (cached) yes
checking for sys/socket.h... yes
checking host CPU and C ABI... x86_64
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for wchar_t... yes
checking whether strerror(0) succeeds... yes
checking for C/C++ restrict keyword... __restrict
checking for pid_t... yes
checking for mode_t... yes
checking for alloca as a compiler built-in... yes
checking for getloadavg... yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking whether getloadavg is declared... yes
checking for ssize_t... yes
checking for good max_align_t... no
checking whether NULL can be used in arbitrary expressions... yes
checking for working strerror function... yes
checking for ranlib... (cached) ranlib
checking how to run the C preprocessor... gcc -E
checking for ar... ar
checking for perl... perl
checking for library containing strerror... none required
checking whether byte ordering is bigendian... no
checking for a sed that does not truncate output... /usr/bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes

Re: [PATCH] Pacify Oracle Studio 12.6 in init_switches

[Dennis Clarke]

On 8/27/19 3:40 AM, Paul Eggert wrote:

* src/main.c (init_switches): Use a cast to convert char const *
to char *.  Without this patch, the compiler complains
‘"src/main.c", line 2643: warning: assignment type mismatch:


Using the c99 compiler with realyl strict CFLAGS I see these :

"src/arscan.c", line 43: warning: tokens ignored at end of directive line
"src/dep.h", line 55: warning: nonportable bit-field type
"src/dep.h", line 64: warning: nonportable bit-field type
"src/function.c", line 41: warning: nonportable bit-field type
"src/function.c", line 42: warning: nonportable bit-field type
"src/main.c", line 1054: warning: only 0 or 2 parameters allowed: main()
"src/read.c", line 1405: warning: statement not reached

However the compile proceeds fine.
Testsuite has a multitude of failures.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 'reap_children':
>>>> src/job.c:754:17: error: incompatible type for argument 1 of 'wait'
>>>> EINTRLOOP (pid, wait ());
>>>
>>> That is REALLY disturbing, because it means that configure couldn't
>>> detect either waitpid() or wait3(), both of which have been available
>>> since approximately forever.  Something went badly wrong with the
>>> configure run on this system.
>>
>> I know and it was a show stopper for me.  I just had to stop and stare
>> at my coffee cup after trying this across a bunch of machines.
>
> If I'm reading the downloads you provided correctly it seems there are
> a bunch of extra flags being added to the compile and link lines:
>
>> CFLAGS='-std=iso9899:1999 -m64 -g -march=opteron -Wl,-
>> rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -O0 -malign-double
>> -mpc80'
>> export CFLAGS
Well I have been building software for a while now and none of those
flags are a problem. However let's take a look :

(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.  The GCC manual actually says "GCC has substantially
complete support for this standard version" but that does not mean it
is complete.  GNU make may be in the C89 world or maybe C99.  I do not
know but I can make it compile clean on a very very strict standards
compliant UNIX server with no problem.  So I think C99 is perfectly
safe here. I know from extensive experience and a bit of pain that the
OpenSSL project is firmly entrenched into C89 simply because of the old
massive list of systems that OpenSSL needs to run on.

https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Standards.html#C-Language

(2) This was most likely done on a 64 bit machine and thus -m64 makes
perfect sense here. On the 32 bit i686 and armv7 machines I would need
to specify -m32 or perhaps far more specific options to target a very
specific ARM/Rockchip type SoC like -march=armv7-a and then even a
-mtune=cortex-a17 with -mfpu=vfpv4-d16 which assures me the correct
output assembly being created.

(3) In general I like to be able to single step and debug my way
through lines or whatever so I think a -g is safe everywhere.

(4) On the 64-bit x86_64 type machines where I have both Intel and the
AMD variants on hand it seems like a good idea to go with a baseline
feature set that works cross platform everywhere.  It is possible to go
with a trivial -march=x86-64 however I seem to recall that the first
release of viable 64-bit processors was done by AMD and they used the
product name "Opteron" at the time.  This was a massively successful
processor design which Sun Microsystems jumped on and they started to
push out servers by the truck load. Very quickly we saw the open source
world flood in and before you knew it everything was "AMD64" here there
and everywhere. Here we are about eighteen years later and the original
"SledgeHammer" name has been forgotten but every Debian kernel released
for everything 64-bit always says amd64 in the revision tag such as the
current stable 4.19.0-5-amd64.  Regardless of the "amd64" tag most of
the GNU host and target triplets will utter :

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu

So that is fine.  The k8 or opteron tag merely indicates that there are
a very few 64-bit extensions to the opcode instruction set on the chip
and https://en.wikipedia.org/wiki/Opteron#Two_key_capabilities sort of
shows the history of what happened back then.  Everyone jumped on the
k8 and Intel still had their Itanium which was not selling well. Most
folks don't know that Sun Microsystems had a beautiful ready to release
port of their Solaris UNIX operating system for the Itanium but it was
wrapped in plastic and shoved into a shelf somewhere in the same large
warehouse seen in Raiders of the Lost Ark. Along with the port done for
the IBM Power based mainframes but that saw the light of day at the
press release and COMDEX and then quickly hidden. However I digress.

(5) -Wl,-rpath=/opt/bw/lib has nothing to say to the compiler but it is
good instructions for the linker stage wherein we want the output ELF
dynamic section to include RPATH data. The horror show usage of things
like LD_LIBRARY_PATH should be avoided at all costs as that leads to
slow insanity. A binary executable should have some hint for the run
time linker where to look for whatever libs it n

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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 ());


That is REALLY disturbing, because it means that configure couldn't
detect either waitpid() or wait3(), both of which have been available
since approximately forever.  Something went badly wrong with the
configure run on this system.


I know and it was a show stopper for me.  I just had to stop and stare
at my coffee cup after trying this across a bunch of machines.

The entire configure log is there in the tarball and I may stare at it
tomorrow.


Thanks for sending me links to the other stuff.  I haven't looked at
them all yet but there seems to be a combination of two things:

First the glob.c/wildcard error. 



Yeah .. that one.   :-\


Note that this is not a new error:
it's always been like this.  What's new  is (a) the test which shows
the problem, and (b) that it _doesn't_ fail on some sufficiently new
systems.


Right !!   I did this and had others watching and we were all wondering
why Debian stable was happy and Debian sid had a fit. Of course there
was also the x86_64 versus i686 architecture there too.



 It's not clear this can be fixed, at least for GNU libc-based
systems of a certain vintage.  In any even it's probably a bug that
needs to be file with the system.


Everything I have is very very recent.


The second group appears to be for systems that handle posix_spawn()
errors differently.  If you check the POSIX spec you'll see that error
handling for posix_spawn() is very tricky.  


POSIX .. I have heard of that :)


Some systems will fail
posix_spawn() if the program to be invoked doesn't exist (this is how
GNU/Linux and MacOS work).  Other programs will have posix_spawn()
succeed, but then fail the process later.  I think this latter behavior
is what you're seeing on the systems where you get a lot of errors.
The diffs I've seen so far are about missing "no such file" messages.

I thought about trying to handle this but (1) it's a bit annoying and
(2) I didn't know if there were any systems that used this latter
behavior.  Looks like there might be.



Sounds like whiskey in my coffee cup tomorrow to look at this all again.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

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: https://www.gnu.org/software/make/
 

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:  https://alpha.gnu.org/gnu/make/

- NEWS 


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 ());
 ^
In file included from src/job.c:126:0:
/usr/include/sys/wait.h:114:16: note: expected '__WAIT_STATUS' but 
argument is of type 'int *'

 extern __pid_t wait (__WAIT_STATUS __stat_loc);
^
gmake[1]: *** [Makefile:1207: src/job.o] Error 1
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_rhel_74_3.10.0-693.el7.x86_64.001'

gmake: *** [Makefile:1293: all-recursive] Error 1

I have seen that on no other system thus far today.
So that is a bit odd.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional


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

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

[Dennis Clarke]

On 8/26/19 5:51 PM, Paul Smith wrote:

On Mon, 2019-08-26 at 17:42 -0400, Dennis Clarke wrote:

Well I am getting consistent results here on a number of systems
across various OS and platform architectures.  A few of them fail in
the test functions/wildcard and I see :


This one (the __ldir test) is exactly the one I was referring to as
failing on MacOS: it's a bug in handling symlinks in the older
glob.c/fnmatch.c implementation we have.  This bug has been fixed in
GNU libc (and the later gnulib implementations).

This doesn't fail on GNU/Linux systems, if they choose the system GNU
libc (and it has this bug fixed--older systems may not).



It does fail everywhere with the exception of a single Debian Linux
x86_64 system.  On 32-bit Debian systems there are many many failures
on both arm and i686.



I'd be interested to see the diffs generated on these other systems.
If convenient, please tar them up and send them to me directly (no need
to send them to the list).



Alrighty then I will tarball up stuff wherein there is information in
each tarball about the environment, the compiler and then the testsuite
results. Hope we can get a clean release that runs everywhere or at
least nearly everywhere.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional





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

Re: GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

[Dennis Clarke]

On 8/26/19 4:32 PM, Paul Smith wrote:

On Mon, 2019-08-26 at 16:19 -0400, Dennis Clarke wrote:

Testing on a few system and seems to fail the testsuite in various
ways on multiple systems. Does not compile on FreeBSD 12.0-RELEASE-
p10 amd64 with LLVM/Clang thus :


Thanks Dennis.

Please note that glob/fnmatch/getopt are not technically supported by
GNU make, so I don't apply patches for them to fix warnings unless they
are actual errors in the code.  Ditto for general code cleanup to these
files.



Sadly I just wrote a 600 line patch. Fixes the issues and the warnings
and the point type mismatch.


I recommend you don't compile with -Werror.


I tend to be a bit pedantic on a release candidate just to shake out the
code.



If you find warnings to other files in src/ I'm interested in that.

To fix this we'd need to start using the current gnulib versions of
these files instead of the old ones we have now, and then if there are
broken things they can get fixed there.


   * nod *


As an example, when I run the regression tests on MacOS one of them
fails in the symlink tests because (I believe) it's using the older
glob.c/fnmatch.c we provide.  On GNU/Linux we use the versions that are
provided with the system libc (because it's glibc).

The reason this is difficult is because I'm not sure that the gnulib
versions of glob/fnmatch work well with Windows (and VMS?)... or if
they do what the best way to integrate them with gnu make is.  I'll
look into it.



Well I am getting consistent results here on a number of systems across
various OS and platform architectures.  A few of them fail in the test
functions/wildcard and I see :

vesta$
vesta$ uname -apKU
FreeBSD vesta 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64 
amd64 1200086 1200086

vesta$ cc --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on 
LLVM 6.0.1)

Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
vesta$ find . | grep 'diff'
./tests/work/functions/wildcard.diff.7
vesta$ cat ./tests/work/functions/wildcard.diff.7
*** work/functions/wildcard.base.7  Mon Aug 26 21:30:53 2019
--- work/functions/wildcard.log.7   Mon Aug 26 21:30:53 2019
***
*** 1 
! __ldir
--- 1 
!
vesta$

OKay over on ppc64 FreeBSD 13-CURRENT I see the exact same result while
using gcc 8.2.0 there.

Debian Linux "sid" on i686 with gcc 9.2.0 throws a ton of failures :

esther$
esther$ uname -a
Linux esther 5.2.0-2-686 #1 SMP Debian 5.2.9-2 (2019-08-21) i686 GNU/Linux
esther$ gcc --version
gcc (Debian 9.2.1-4) 9.2.1 20190821
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

esther$

esther$ find . | grep 'diff'
./tests/work/targets/SECONDARY.diff.3
./tests/work/targets/INTERMEDIATE.diff.2
./tests/work/targets/INTERMEDIATE.diff.5
./tests/work/targets/SECONDARY.diff.2
./tests/work/features/archives.diff.1
./tests/work/features/archives.diff.4
./tests/work/features/reinvoke.diff.1
./tests/work/features/archives.diff.2
./tests/work/features/archives.diff.6
./tests/work/features/output-sync.diff.12
./tests/work/features/output-sync.diff.11
./tests/work/features/archives.diff.3
./tests/work/features/reinvoke.diff.3
./tests/work/features/reinvoke.diff
./tests/work/features/archives.diff.5
./tests/work/features/vpathplus.diff.3
./tests/work/features/reinvoke.diff.2
./tests/work/features/load.diff.3
./tests/work/options/symlinks.diff.1
./tests/work/options/symlinks.diff.6
esther$


I don't even know where to begin on that machine.

Debian 9.9 on 32-bit arm7 fails the wildcard test with identical
results to the FreeBSD systems :

arm7$ uname -a
Linux arm7 4.4.132+ #1 SMP Wed May 15 19:37:54 CST 2019 armv7l GNU/Linux
arm7$ cat /etc/debian_version
9.9
arm7$ gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm7$
arm7$ cat ./tests/work/functions/wildcard.diff.7
*** work/functions/wildcard.base.7  Mon Aug 26 19:14:47 2019
--- work/functions/wildcard.log.7   Mon Aug 26 19:14:47 2019
***
*** 1 
! __ldir
--- 1 
!
arm7$


The Solaris 10 SPARC machine blows up in so many places I don't even
know where to begin. It compiles clean. Perfect with Oracle Studio c99
and with strict CFLAGS but the testsuite fails in a spectacular fashion:

beta$ find . | grep 'diff'
./tests/work/features/errors.diff.4
./tests/work/features/errors.diff.3
./tests/work/features/vpathplus.diff.2
./tests/work/features/archives.diff.10
./tests/work/features/load.diff.3
./tests/work/features/output-sync.diff.14
./tests/work/features/errors.diff.5
./tests/work/features/load.diff.4
./tests/work/features/grouped_targets.diff
./tests/wor

GNU make 4.2.90 rc passes testsuite no where except Linux x86_64 thus far

[Dennis Clarke]

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: https://www.gnu.org/software/make/
 

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:  https://alpha.gnu.org/gnu/make/

- NEWS 

Version 4.2.90 (26 Aug 2019)

A complete list of bugs fixed in this version is available here:



Testing on a few system and seems to fail the testsuite in various ways
on multiple systems. Does not compile on FreeBSD 12.0-RELEASE-p10 amd64
with LLVM/Clang thus :

vesta$ $CC --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on 
LLVM 6.0.1)

Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
vesta$

vesta$ echo $CFLAGS
-m64 -std=c99 -O0 -g -Werror -no-integrated-as -fno-fast-math 
-fno-builtin -fdiagnostics-format=vi -fno-color-diagnostics

vesta$

Saw this :



/usr/bin/cc -DHAVE_CONFIG_H -I. -I../src   -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -m64 -std=c99 -O0 -g 
-Werror -no-integrated-as -fno-fast-math -fno-builtin 
-fdiagnostics-format=vi -fno-color-diagnostics -MT glob.o -MD -MP -MF 
.deps/glob.Tpo -c -o glob.o glob.c
glob.c +823:27: error: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * 
[-Werror,-Wincompatible-pointer-types]

= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
glob.c +942:24: error: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * 
[-Werror,-Wincompatible-pointer-types]

= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
glob.c +997:39: error: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * 
[-Werror,-Wincompatible-pointer-types]

  new_pathv = (char **) realloc (pglob->gl_pathv,
 ^~~
 *
glob.c +1388:23: error: incompatible pointer types passing 'char **' to 
parameter of type 'char *'; dereference with * 
[-Werror,-Wincompatible-pointer-types]

= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
4 errors generated.
gmake[3]: *** [Makefile:888: glob.o] Error 1
gmake[3]: Leaving directory 
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'

gmake[2]: *** [Makefile:908: all-recursive] Error 1
gmake[2]: Leaving directory 
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'

gmake[1]: *** [Makefile:814: all] Error 2
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001/lib'

gmake: *** [Makefile:1293: all-recursive] Error 1
vesta$

So that should be just a mismatch on the types.
I have already patched that here locally.


Also :


/usr/bin/cc -DHAVE_CONFIG_H   -Isrc -I./src -Ilib -I./lib 
-DLIBDIR=\"/opt/bw/lib\" -DINCLUDEDIR=\"/opt/bw/include\" 
-DLOCALEDIR=\"/opt/bw/share/locale\"  -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -m64 -std=c99 -O0 -g 
-Werror -no-integrated-as -fno-fast-math -fno-builtin 
-fdiagnostics-format=vi -fno-color-diagnostics -MT src/getopt.o -MD -MP 
-MF $depbase.Tpo -c -o src/getopt.o src/getopt.c &&\

mv -f $depbase.Tpo $depbase.Po
src/getopt.c +685:6: error: add explicit braces to avoid dangling else 
[-Werror,-Wdangling-else]

   else
   ^
1 error generated.
gmake[1]: *** [Makefile:1207: src/getopt.o] Error 1
gmake[1]: Leaving directory 
'/opt/bw/build/make-4.2.90_FreeBSD_12.0-p10_amd64.001'

gmake: *** [Makefile:1293: all-recursive] Error 1

That seems a bit pedantic.

I am walking through the function _getopt_internal and doing some code
cleanup.

I also have 32-bit Debian on arm and FreeBSD on ppc64 and Solaris on
Fujitsu SPARC and other systems.  They all fail the testsuite in various
ways.  For now.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

[bug #56701] Do not allow -j without a number

[Dennis Clarke]

Follow-up Comment #5, bug #56701 (project make):

Well gnulib is not what I call portable. So if the sysconf/getconf calls
are not around to give us _NPROCESSORS_ONLN or even _NPROCESSORS_CONF
then no way should some hack attempt be made to extract that data. No
promise the data is available at all in a portable manner anyways and
get_nprocs_conf should be entirely avoided. 

The "defacto" standard which has worked for the past three decades
should not be messed with unless there exist some really amazingly
solid arguments.  As for a system exhausting all resources due to a
badly specified set of parameters to "make" one could argue that any
user can do worse damage with "rm -rf *" and that is the users issue
entirely.  Giving the user a hug should not be required here.

Dennis 


___

Reply to this item at:

  

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


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

Re: [bug #56701] Do not allow -j without a number

[Dennis Clarke]

On 8/26/19 1:46 PM, Dennis Clarke wrote:

On 8/26/19 1:32 PM, David Boyce wrote:
My vote is to leave -j alone. Everyone knows it shouldn't be used that 
way in production...


Please allow me to follow up here and agree. Common sense should prevail
and in the true sense of UNIX and Linux philosophy a tool does one thing
and does that one thing well. It should need to hand hold the user with
common sense.


Should NOT need to hand hold the user.

Also gnulib is not what I call portable. So if the sysconf/getconf calls
are not around to give us _NPROCESSORS_ONLN or even _NPROCESSORS_CONF
then no way should some hack attempt be made to extract that data. No
promise the data is available at all in a portable manner anyways and
get_nprocs_conf should be entirely avoided.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: [bug #56701] Do not allow -j without a number

[Dennis Clarke]

On 8/26/19 1:32 PM, David Boyce wrote:
My vote is to leave -j alone. Everyone knows it shouldn't be used that 
way in production...


Please allow me to follow up here and agree. Common sense should prevail
and in the true sense of UNIX and Linux philosophy a tool does one thing
and does that one thing well. It should need to hand hold the user with
common sense.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

[bug #56749] Any chance to make new release?

[Dennis Clarke]

Follow-up Comment #1, bug #56749 (project make):

I really must agree. 

At this time the make 4.2.1 release from 6 Jun 2016 will not
compile cleanly on modern Linux systems with modern glibc.

There are a number of small patches required on different 
systems and kernel revs however it does seem to compile 
clean on FreeBSD UNIX and Oracle Solaris 10.

Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56749>

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


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

Re: Is there a new release anytime soon given that 4.2.1 has multiple issues?

[Dennis Clarke]

On 4/30/19 9:44 AM, Paul Smith wrote:

On Sun, 2019-04-28 at 16:51 -0400, Dennis Clarke wrote:

So then.  New release ?


Yes, it's on deck.  I know I've said this before.

I'm finishing up a huge months-long project at $RealJob.  All the major
code is finally done and pushed.

This week is filled with graduation events (not mine! :)) so this
weekend/next week I expect to start triaging bugs, applying patches,
and getting things in order for GNU make.

I will announce beta releases.  Anyone interested in testing please
stay tuned.



Thing of beauty !

Thank you for the reply.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Is there a new release anytime soon given that 4.2.1 has multiple issues?

[Dennis Clarke]

I think this has been covered over and over and with little reply or
progress. The main page for GNU Make[1] says little and the development
page[2] says "Latest News"[3] is 4.2.1.

The 4.2.1 release simply won't build out-of-the-box on any modern linux
with up to date glibc anymore. My approach[4] was to patch configure.ac
and then try to get around the problems in glob.c with some elegance.

The "Linux From Scratch" people merely say "nuke it out of orbit"[5]
with an outright delete of a bunch of lines therein. Regardless Debian
sid on bone stock x86_64 hardware reports strange results in the
testsuite after some hacks just to get a compile going.

So then.  New release ?

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

[1] https://www.gnu.org/software/make/

[2] https://savannah.gnu.org/projects/make/

[3] https://savannah.gnu.org/forum/forum.php?forum_id=8572

[4] https://lists.gnu.org/archive/html/bug-make/2019-01/msg2.html

[5] http://www.linuxfromscratch.org/lfs/view/development/chapter05/make.html

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

Re: [bug #55691] New make release plan

[Dennis Clarke]

On 2/11/19 4:21 AM, Tomasz Kłoczko wrote:

URL:
   <https://savannah.gnu.org/bugs/?55691>

  Summary: New make release plan
  Project: make
 Submitted by: kloczek
 Submitted on: Mon 11 Feb 2019 09:21:38 AM UTC
 Severity: 3 - Normal
   Item Group: None
   Status: None
  Privacy: Public
  Assigned to: None
  Open/Closed: Open
  Discussion Lock: Any
Component Version: None
 Operating System: None
Fixed Release: None
Triage Status: None

 ___

Details:

Looks like last time make has been released ~2.5 years ago.
Do you have any plans to do new release?



I have seen complaints in various places that the "current" release
is broken in that it fails certain tests and fails to compile with
a very recent glibc.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: Shell function and LD_LIBRARY_PATH

[Dennis Clarke]

On 1/20/19 8:47 PM, Mohammad Akhlaghi wrote:

Thank you very much for the prompt replies, they were very useful.

In the end (for the time being!), I am using patchelf. I couldn't find a 
way to configure Bash with RPATH (I still haven't stopped searching, but 
I need to progress for now).



I have not followed the entire thread and I am certain that this has
been looked at but doesn't -Wl,-rpath=/usr/local/lib do the necessary
passing to the ld stage?

Dennis


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

make-4.2.1 fails wildcard.diff.4 and wildcard.diff.5 on Debian testing for ppc64

[Dennis Clarke]

In actual fact I see these failures on multiple systems today while
trying to run the testsuite.

One item of logistics is this gem :

hydra$ cat ../../src/make_4.2.1_patch_01.u
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],
hydra$
hydra$
hydra$ /usr/bin/patch --backup --verbose -p0 -i 
../../src/make_4.2.1_patch_01.u

Hmm...  Looks like a new-style context diff to me...
The text leading up to this was:
--
|*** configure.ac_backupMon Jun  6 12:27:31 2016
|--- configure.ac   Mon Apr  2 16:57:41 2018
--
patching file configure.ac
Using Plan A...
Hunk #1 succeeded at 399.
done
hydra$

That is *needed* on any up to date system with glibc and thus I have to
 run autoconf again to get configure and that runs fine :

hydra$
hydra$ ./configure --prefix=/opt/bw --program-prefix=g 
--disable-silent-rules --enable-dependency-tracking --with-gnu-ld

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... /usr/bin/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 /usr/bin/gcc accepts -g... yes
checking for /usr/bin/gcc option to accept ISO C89... none needed
checking whether /usr/bin/gcc understands -c and -o together... yes
checking dependency style of /usr/bin/gcc... gcc3
checking how to run the C preprocessor... /usr/bin/gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /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 minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) /usr/bin/gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether /usr/bin/gcc accepts -g... (cached) yes
checking for /usr/bin/gcc option to accept ISO C89... (cached) none needed
checking whether /usr/bin/gcc understands -c and -o together... (cached) yes
checking dependency style of /usr/bin/gcc... (cached) gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... /usr/bin/gcc -E
checking for ar... ar
checking for perl... perl
checking the archiver (ar) interface... ar
checking build system type... powerpc64-unknown-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking for library containing strerror... none required
checking for a sed that does not truncate output... /bin/sed
checking whether NLS is requested... yes
checking for msgfmt... no
checking for gmsgfmt... :
checking for xgettext... no
checking for msgmerge... no
checking for ld used by /usr/bin/gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for library containing getpwnam... none required
checking for ANSI C header files... (cached) yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether stat file-mode macros are broken... no
checking whether time.h and sys/time.h may both be included... yes
checking for stdlib.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for unistd.h... (cached) yes
checking limits.h 

Re: No follow up on patches to support newer glibc ?

[Dennis Clarke]

On 04/04/18 03:42 PM, Paul Smith wrote:

On Wed, 2018-04-04 at 13:03 -0400, Dennis Clarke wrote:

After all the vibrant discussion I was at least expecting a reply that
says "okay .. so that works" or perhaps a "ver 4.2.2 patches?" or
something.


Well, we thought it would work and it did work, and those fixes are in
the codebase... so win!

It does look like we need to make a new release soon.



A minor release anyways.



What bothers me is that these patches are only needed on a i686 system
thus far.


I find that difficult to understand.  Are you SURE you're using the
exact same GNU libc on all the different systems?


Ignore me .. that is wrong. I did have make 4.2.1 on multiple systems
but I went back and did an update in a few places and some tests and
the make I had previously built was with :

nix$ readelf -delVt `whicjh gmake`
.
.
.
Version needs section '.gnu.version_r' contains 2 entries:
 Addr: 0x10004a78  Offset: 0x004a78  Link: 6 (.dynstr)
  00: Version: 1  File: libdl.so.2  Cnt: 1
  0x0010:   Name: GLIBC_2.3  Flags: none  Version: 5
  0x0020: Version: 1  File: libc.so.6  Cnt: 3
  0x0030:   Name: GLIBC_2.17  Flags: none  Version: 4
  0x0040:   Name: GLIBC_2.4  Flags: none  Version: 3
  0x0050:   Name: GLIBC_2.3  Flags: none  Version: 2

ah ha ... well now I have this :

nix$ ldd --version
ldd (Debian GLIBC 2.27-3) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
nix$

Yes the problem exists.


As I pointed out in a previous post, this has no relationship to the
underyling architecture, compiler, etc.  As far as I understanding it
this issue comes solely from the version of GNU libc you're using.


Seems to be exactly the case too.

Note those patches are not the same as what you have in your links to
git diff reports. I had to make changes to get them to work against the
release tarball.

Dennis



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

No follow up on patches to support newer glibc ?

[Dennis Clarke]

After all the vibrant discussion I was at least expecting a reply that
says "okay .. so that works" or perhaps a "ver 4.2.2 patches?" or
something.

What bothers me is that these patches are only needed on a i686 system
thus far.


Dennis



---
FILE : make-4.2.1_linux_4.15.15-genunix_i686.005.patch01
---
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],


---
FILE make-4.2.1_linux_4.15.15-genunix_i686.005.patch02
---
*** dir.c.orig  2016-05-31 07:17:26.0 +
--- dir.c   2018-04-03 03:25:44.892913153 +
***
*** 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! # ifndef VMS
! #  ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #  endif
! # else
! /* We are done with the fake stat.  Go back to the real stat */
! #   ifdef stat
! # undef stat
! #   endif
! # endif
! # define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
--- 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake stat.  Go back to the real stat */
! #ifdef stat
! #undef stat
! #endif
! #endif
! #define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
***
*** 1293,1300 
  return -1;
  }
  #endif

!   EINTRLOOP (e, stat (path, buf));
return e;
  }
  #endif
--- 1293,1322 
  return -1;
  }
  #endif
+ #endif

! /* Similarly for lstat.  */
! #if !defined(lstat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
! int lstat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake lstat.  Go back to the real lstat */
! #ifdef lstat
! #undef lstat
! #endif
! #endif
! #define local_lstat lstat
! #elif defined(WINDOWS32)
! /* Windows doesn't support lstat().  */
! #define local_lstat local_stat
! #else
! static int
! local_lstat (const char *path, struct stat *buf)
! {
!   int e;
!   EINTRLOOP (e, lstat (path, buf));
return e;
  }
  #endif
***
*** 1305,1313 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
gl->gl_stat = local_stat;
-   /* We don't bother setting gl_lstat, since glob never calls it.
-  The slot is only there for compatibility with 4.4 BSD.  */
  }

  void
--- 1327,1334 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
+   gl->gl_lstat = local_lstat;
gl->gl_stat = local_stat;
  }

  void




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

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 02/04/18 02:00 PM, Paul Smith wrote:

On Mon, 2018-04-02 at 13:55 -0400, Dennis Clarke wrote:

Not sure what to do with that.


You may need this:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=193f1e81edd6b1b56b0eb0ff8aa4b41c7b4257b4

Or, latest from Git HEAD.


I started over from the top and only used the release 4.2.1 tarball.

Managed to get everything to work however I need PERL_USE_UNSAFE_INC=1
to run the testsuite.

Here are the results and the patches.

---
FILE : make-4.2.1_linux_4.15.15-genunix_i686.005.patch01
---
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],


---
FILE make-4.2.1_linux_4.15.15-genunix_i686.005.patch02
---
*** dir.c.orig  2016-05-31 07:17:26.0 +
--- dir.c   2018-04-03 03:25:44.892913153 +
***
*** 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! # ifndef VMS
! #  ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #  endif
! # else
! /* We are done with the fake stat.  Go back to the real stat */
! #   ifdef stat
! # undef stat
! #   endif
! # endif
! # define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
--- 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake stat.  Go back to the real stat */
! #ifdef stat
! #undef stat
! #endif
! #endif
! #define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
***
*** 1293,1300 
  return -1;
  }
  #endif

!   EINTRLOOP (e, stat (path, buf));
return e;
  }
  #endif
--- 1293,1322 
  return -1;
  }
  #endif
+ #endif

! /* Similarly for lstat.  */
! #if !defined(lstat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
! int lstat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake lstat.  Go back to the real lstat */
! #ifdef lstat
! #undef lstat
! #endif
! #endif
! #define local_lstat lstat
! #elif defined(WINDOWS32)
! /* Windows doesn't support lstat().  */
! #define local_lstat local_stat
! #else
! static int
! local_lstat (const char *path, struct stat *buf)
! {
!   int e;
!   EINTRLOOP (e, lstat (path, buf));
return e;
  }
  #endif
***
*** 1305,1313 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
gl->gl_stat = local_stat;
-   /* We don't bother setting gl_lstat, since glob never calls it.
-  The slot is only there for compatibility with 4.4 BSD.  */
  }

  void
--- 1327,1334 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
+   gl->gl_lstat = local_lstat;
gl->gl_stat = local_stat;
  }

  void

Setup a few env vars and here I use CFLAGS with c99 specified but NOT 
the pedantic warnings or errors.


phobos_$ env | sort
BUILD=/usr/local/build
CC=gcc
CFLAGS=-m32 -march=i386 -g -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO

CONFIG_SHELL=/bin/bash
CPPFLAGS=-I/usr/local/include
CXXFLAGS=-m32 -march=i386 -g -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO

CXX=g++
EDITOR=/usr/bin/vi
LANG=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LD_OPTIONS=-R/usr/local/lib -L/usr/local/lib
LD_RUN_PATH=/usr/local/lib
PAGER=more
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/sbin:/bin:/usr/sbin
PWD=/usr/local/build
SHELL=/bin/bash
SHLVL=1
SRC=/usr/local/src
TERM=vt100
TMPDIR=/var/tmp/dclarke
TZ=GMT0
USER=dclarke
_=/usr/bin/env
VISUAL=/usr/bin/vi


Apply those patches neatly to the tarball sources :


phobos_$ patch --verbose --backup < 
../make-4.2.1_linux_4.15.15-genunix_i686.005.patch01

Hmm...  Looks like a new-style context diff t

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 02/04/18 01:15 PM, Martin Dorey wrote:

checking whether closedir returns void... no
./configure: line 9678: PKG_PROG_PKG_CONFIG: command not found
./configure: line 9690: syntax error near unexpected token `GUILE,'
./configure: line 9690: `   PKG_CHECK_MODULES(GUILE, guile-2.0,
have_guile=yes,'
debi686$


Perhaps it's:



progress here .. sort of :

debi686$
debi686$ ldd make
linux-gate.so.1 (0xb7f4e000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7efe000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d25000)
/lib/ld-linux.so.2 (0xb7f5)
debi686$ ./make --version
GNU Make 4.2.1
Built for i686-pc-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
debi686$

debi686$ export PERL_USE_UNSAFE_INC=1
debi686$ /usr/bin/time -p /usr/bin/make check 2>&1 | tee 
../make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4.check.log 


Making check in glob
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/glob'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/glob'

Making check in config
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/config'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/config'

Making check in po
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/po'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/po'

Making check in doc
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/doc'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/doc'
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'

/usr/bin/make  loadavg
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'
make[2]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'

/usr/bin/make  check-local
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'
cd tests && perl ./run_make_tests.pl -srcdir 
/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4 
-make ../make

--
   Running tests for GNU make on Linux phobos 4.15.15-genunix i686
GNU Make 4.2.1
--

Finding tests...

features/archives ... ok (10 passed)
features/comments ... ok (1 passed)
features/conditionals ... ok (5 passed)
features/default_names .. ok (3 passed)
features/double_colon ... ok (14 passed)
features/echoing  ok (4 passed)
features/errors . ok (3 passed)
features/escape . ok (8 passed)
features/export . ok (12 passed)
features/include  ok (15 passed)
features/jobserver .. ok (6 passed)
features/load ... ok (5 passed)
features/loadapi  ok (3 passed)
features/mult_rules . ok (2 passed)
features/mult_targets ... ok (2 passed)
features/order_only . ok (10 passed)
features/output-sync  ok (15 passed)
features/override ... ok (4 passed)
features/parallelism  ok (9 passed)
features/patspecific_vars ... 

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

I don't know why that would have only kicked off now but, in my limited 
experience, autotools often works in ways that are similarly mysterious to me.




Yeah .. black magic under a full moon.  :-\

Let's just do a git head pull here and give that a whirl.

Dennis


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

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

you went offlist .. let's not.

OK, I just was on a phone client that does not know my "real" email address,
used by the list, sorry.



no biggie .. it happens.



I meant to suggest to have a look at the output of ldd, to see
if there is anything weird there. E.g. I have (on the latest Fedora):

$ ldd `which make`
/usr/bin/make:
 linux-vdso.so.1 (0x7fff2dcbc000)
 libguile-2.0.so.22 => /lib64/libguile-2.0.so.22 (0x7f7cc7d0)
 libgc.so.1 => /lib64/libgc.so.1 (0x7f7cc79a4000)
 libdl.so.2 => /lib64/libdl.so.2 (0x7f7cc77a)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7cc7581000)
 libc.so.6 => /lib64/libc.so.6 (0x7f7cc71ac000)
 libffi.so.6 => /lib64/libffi.so.6 (0x7f7cc6fa4000)
 libunistring.so.2 => /lib64/libunistring.so.2 (0x7f7cc6c32000)
 libgmp.so.10 => /lib64/libgmp.so.10 (0x7f7cc69bb000)
 libltdl.so.7 => /lib64/libltdl.so.7 (0x7f7cc67b1000)
 libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f7cc657b000)
 libm.so.6 => /lib64/libm.so.6 (0x7f7cc6265000)
 /lib64/ld-linux-x86-64.so.2 (0x7f7cc82c8000)
 libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f7cc6062000)
 libfreebl3.so => /lib64/libfreebl3.so (0x7f7cc5e5f000)



That looks bonkers to me ... Red Hat ?   Nope .. even on a RHEL 7.4 
system I have :


-bash-4.2$ which make
/bin/make
-bash-4.2$ ldd /bin/make
linux-vdso.so.1 =>  (0x7fff205fd000)
libc.so.6 => /lib64/libc.so.6 (0x7fd570f2)
/lib64/ld-linux-x86-64.so.2 (0x562392bba000)
-bash-4.2$
-bash-4.2$ uname -r
3.10.0-693.17.1.el7.x86_64
-bash-4.2$


Here on the debian sid i686 unit I have :

debi686$ which make
/usr/bin/make
debi686$ ldd /usr/bin/make
linux-gate.so.1 (0xb7f2f000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7edf000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d06000)
/lib/ld-linux.so.2 (0xb7f31000)


So no bonkers dependencies.

Dennis

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

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 02/04/18 11:24 AM, Martin Dorey wrote:

 > why this current release code won't work

https://lists.gnu.org/archive/html/info-gnu/2016-06/msg5.html says 
make-4.2.1 is from 2016-06-11.  In the email thread I cited previously, 
for what looked like the same errors, we see Paul writing, over a year 
after that release, on 2017-11-19, "I pushed a change that should allow 
this to work properly".  So the reason that the current release code 
won't work is, I suggest, because there hasn't been a new release that 
includes that change.  Why not cut to the chase, prove it ...


sure thing .. let's do that and make a 4.2.2 release.


Paul's patch was:

http://git.savannah.gnu.org/cgit/make.git/commit/?id=48c8a116a914a325a0497721f5d8b58d5bba34d4


That doesn't strictly line up anymore .. close enough :

debi686$ diff -c configure.ac_backup configure.ac
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],




>Still, perhaps you could patch whatever file the

configure script is generating there as a quick proof of concept.



Doing a quick hack on the 4.2.1 release tarball first.

debi686$ autoreconf -v -f
autoreconf: Entering directory `.'
autoreconf: configure.ac: not running autopoint: --install not given
autoreconf: running: aclocal --force -I config
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --force-missing
autoreconf: Leaving directory `.'
debi686$

well .. this is weird :

debi686$ ./configure --prefix=/usr/local --program-prefix=g \
> --disable-silent-rules --enable-dependency-tracking \
> --with-gnu-ld --without-libiconv-prefix \
> --without-libintl-prefix 2>&1 | tee 
../make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4.config.log

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
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 dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /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 minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for ar... ar
checking for perl... perl
checking the archiver (ar) interface... ar
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for library containing strerror... none required
checking for a sed that does not truncate output... /bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 02/04/18 10:21 AM, Dmitrii Pasechnik wrote:

Hi,
I just wonder whether this is a relatively common case of an updated 
make dependence, which is incompatible on the binary level (e.g. due to 
wrong minor version number).
E.g. if your make has guile extension enabled, it is easy to shoot 
yourself in the foot by hacking on one of libguile dependencies...




you went offlist .. let's not.

Also, not sure how to check for whatever it is you suggest.

root@phobos:~# which make
/usr/bin/make
root@phobos:~# file /usr/bin/make
/usr/bin/make: ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for 
GNU/Linux 2.6.32, 
BuildID[sha1]=fcdb8756a78eb97afc306cc2c6acce391bfafbc3, stripped

root@phobos:~#

Dennis


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

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 01/04/18 05:29 PM, Paul Smith wrote:

On Sun, 2018-04-01 at 16:56 -0400, Dennis Clarke wrote:

So I could just lift that out of glibc 2.27 and drop it into the make
   source tree and have a go at it.  Is that the idea here ?


You could try, but I'm not optimistic that it will just work.


"just work" ?  nope.  not even close.


I think the way forward is to get the latest code from GNU make's Git
repository and see if that works:

https://savannah.gnu.org/git/?group=make



Well sure ... however before I get there I am still baffled why this
current release code won't work on an old 32-bit intel debian server?

I just compiled kernel 4.15.15 on that machine and am running it now.

Certainly if I can compile and run a new kernel on the same machine I
would think I can compile GNU make from sources?  Or am I stretching
here?

root@phobos:~# cat /proc/version
Linux version 4.15.15-genunix (admsys@phobos) (gcc version 7.3.0 (Debian 
7.3.0-13)) #1 SMP Sun Apr 1 22:27:12 UTC 2018




Be sure to read the README.git file for information on building from
Git, rather than from a source distribution (it requires extra packages
to be installed, such as autotools).


yep .. autoreconf and its brethern however I suspect something else is
 going on here.

Dennis

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

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

So I could just lift that out of glibc 2.27 and drop it into the make
  source tree and have a go at it.  Is that the idea here ?



phobos$ ls -lap glob
total 216
drwxr-sr-x 3 dclarke devl  4096 Apr  1 21:08 ./
drwxr-sr-x 9 dclarke devl  4096 Apr  1 21:02 ../
-rw-r--r-- 1 dclarke devl  1748 Jan 13  2013 configure.bat
-rw-r--r-- 1 dclarke devl 25263 Jan 13  2013 COPYING.LIB
drwxr-sr-x 2 dclarke devl  4096 Apr  1 21:02 .deps/
-rw-r--r-- 1 dclarke devl  1855 Feb  1 16:17 flexmember.h
-rw-r--r-- 1 dclarke devl 13510 Feb  1 16:17 fnmatch.c
-rw-r--r-- 1 dclarke devl  2295 Feb  1 16:17 fnmatch.h
-rw-r--r-- 1 dclarke devl 31335 Feb  1 16:17 fnmatch_loop.c
-rw-r--r-- 1 dclarke devl 38745 Feb  1 16:17 glob.c
-rw-r--r-- 1 dclarke devl  6614 Feb  1 16:17 glob.h
-rw-r--r-- 1 dclarke devl  1619 Feb  1 16:17 glob_internal.h
-rw-r--r-- 1 dclarke devl 18314 Apr  1 21:02 Makefile
-rw-r--r-- 1 dclarke devl  1124 Jan 13  2013 Makefile.am
-rw-r--r-- 1 dclarke devl  2046 Jan 13  2013 Makefile.ami
-rw-r--r-- 1 dclarke devl 18293 Jun 10  2016 Makefile.in
-rw-r--r-- 1 dclarke devl   195 Jan 13  2013 SCOPTIONS
-rw-r--r-- 1 dclarke devl  5089 Feb  1 16:17 scratch_buffer.h
-rw-r--r-- 1 dclarke devl  2035 Jan 13  2013 SMakefile
phobos$


nope .. that is a large mistake :

phobos$ make
make  all-recursive
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.13.0-1-686_i686.002'

Making all in glob
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.13.0-1-686_i686.002/glob'
gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include  -m32 -march=i386 -g 
-std=iso9899:1999 -Wl,-rpath=/usr/local/lib -D_POSIX_PTHREAD_SEMANTICS 
-D_TS_ERRNO -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o glob.c

In file included from glob.c:79:0:
./scratch_buffer.h:69:11: error: unknown type name ‘max_align_t’
   union { max_align_t __align; char __c[1024]; } __space;
   ^~~
./scratch_buffer.h:95:1: warning: return type defaults to ‘int’ 
[-Wimplicit-int]

 libc_hidden_proto (__libc_scratch_buffer_grow)
 ^
./scratch_buffer.h: In function ‘libc_hidden_proto’:
./scratch_buffer.h:100:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before ‘{’ token

 {
 ^
./scratch_buffer.h:107:1: error: expected declaration specifiers before 
‘libc_hidden_proto’

 libc_hidden_proto (__libc_scratch_buffer_grow_preserve)
 ^
./scratch_buffer.h:124:1: error: expected declaration specifiers before 
‘libc_hidden_proto’

 libc_hidden_proto (__libc_scratch_buffer_set_array_size)
 ^
glob.c:81:20: error: storage class specified for parameter ‘next_brace_sub’
 static const char *next_brace_sub (const char *begin, int flags) 
__THROWNL;

^~
glob.c:81:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static const char *next_brace_sub (const char *begin, int flags) 
__THROWNL;

 ^~
glob.c:83:22: error: storage class specified for parameter ‘dirent_type’
 typedef uint_fast8_t dirent_type;
  ^~~
glob.c:102:3: error: expected specifier-qualifier-list before ‘dirent_type’
   dirent_type type;
   ^~~
glob.c:98:1: warning: empty declaration
 struct readdir_result
 ^~
glob.c:108:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘readdir_result_type’

 readdir_result_type (struct readdir_result d)
 ^~~
glob.c:138:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:186:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:213:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:224:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:230:12: error: storage class specified for parameter ‘glob_in_dir’
 static int glob_in_dir (const char *pattern, const char *directory,
^~~
glob.c:233:12: error: storage class specified for parameter ‘prefix_array’
 static int prefix_array (const char *prefix, char **array, size_t n) 
__THROWNL;

^~~~
glob.c:233:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static int prefix_array (const char *prefix, char **array, size_t n) 
__THROWNL;

 ^~
glob.c:234:12: error: storage class specified for parameter 
‘collated_compare’

 static int collated_compare (const void *, const void *) __THROWNL;
^~~~
glob.c:234:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static int collated_compare (const void *, const void *) __THROWNL;
 ^~
glob.c:241:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:252:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:289:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:1172:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

On 01/04/18 02:58 PM, Paul Smith wrote:

On Sun, 2018-04-01 at 14:54 -0400, Paul Smith wrote:

The contents of the glob/ directory are actually taken directly from
glibc (although at this point an extremely old version) not developed
by GNU make.


Oh, or Martin's reply.  I guess I'm getting really old since this rang
zero bells for me and it was barely 5 months ago... sigh.



Hrmmm .. well thank you both for the reply but I am left wondering what 
actions to take here, if any. I have very up to date glibc now :



phobos$ ldd --version
ldd (Debian GLIBC 2.27-2) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Also I went and fetched the sources and am curious where this "glob" is 
to be found :


phobos$ pwd
/usr/local/build/glibc-2.27

Wherein I see :

./posix/glob.c

Lovely name glob .. but regardless the diff between this and the glob.c 
inside the make sources isn't trivial :


phobos$ diff ../make-4.2.1_linux_4.13.0-1-686_i686.001/glob/glob.c 
./posix/glob.c | wc -l

2310

So I could just lift that out of glibc 2.27 and drop it into the make
 source tree and have a go at it.  Is that the idea here ?

Dennis

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

Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

[Dennis Clarke]

I have the sources to make 4.2.1 and the system currently has make 4.1
and there is nothing in /usr/local/bin at all.

I setup the most trivial environment that I can :

phobos_$ env | sort
COLUMNS=132
EDITOR=/usr/bin/vi
HOME=/home/dclarke
LANG=C
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LINES=43
LOGNAME=dclarke
MAIL=/var/mail/dclarke
OLDPWD=/usr/local/build
PAGER=more
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/opt/schily/bin
PWD=/usr/local/build/make-4.2.1_linux_4.15.12-genunix_i686.003
SHELL=/bin/bash
SHLVL=1
SSH_CLIENT=172.16.35.9 52390 22
SSH_CONNECTION=172.16.35.9 52390 172.16.35.58 22
SSH_TTY=/dev/pts/0
TERM=vt100
TMPDIR=/var/tmp/dclarke
TZ=GMT0
USER=dclarke
VISUAL=/usr/bin/vi
XTERM_LOCALE=C
_=/usr/bin/env
phobos_$

The system gcc is :

phobos_$ gcc --version
gcc (Debian 7.3.0-12) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

phobos_$


Configure goes very well and claims no issues with the non-portable 
'alloca' :


phobos_$ ./configure --prefix=/usr/local --program-prefix=g \
> --disable-silent-rules --enable-dependency-tracking \
> --with-gnu-ld --without-libiconv-prefix \
> --without-libintl-prefix
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
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 dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /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 minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for ar... ar
checking for perl... perl
checking the archiver (ar) interface... ar
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for library containing strerror... none required
checking for a sed that does not truncate output... /bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for library containing getpwnam... none required
checking for ANSI C header files... (cached) yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether stat file-mode macros are broken... no
checking whether time.h and sys/time.h may both be included... yes
checking for stdlib.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for unistd.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for string.h... (cached) yes