.
We surely agree in that regard.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
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
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
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/PP
sync.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
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 opti
load" thingy and could not find it.
Any ideas ?
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
io
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
. 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
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
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
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
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
__
On 9/3/19 9:32 AM, Paul Smith wrote:
On Wed, 2019-08-28 at 17:35 -0400, Dennis Clarke wrote:
This also disables every extension over C, especially POSIX.
Is this a *bad* thing or a *good* thing ? What is the actual language
dialect that GNU Make wishes to be compliant with is the real
On 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
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 doi
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
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 teste
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 particul
ake[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
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
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
'?';
! }
! }
!
! nextchar += strlen (nextchar);
!
! if (longind != NULL)
! *longind = option_index;
!
! if (pfound->flag) {
! *(pfound->flag) = pfound->val;
! return 0;
!
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 e
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'
rc/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.
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
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'
^
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.
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
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
nd 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
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
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
t 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/lis
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/?56
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
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://savanna
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
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 ha
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
***
***
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
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
---
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
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,
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
___
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)
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
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
yourse
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
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
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 reall
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=
53 matches
Mail list logo
