On Tue, 7 Mar 2023, Satish Balay wrote:
> On Tue, 7 Mar 2023, Satish Balay wrote:
>
> > On Tue, 7 Mar 2023, Paul Smith wrote:
> >
> > > FYI I tested on a system I have access to:
>
> > > but it worked fine with the makefile provided (of course I don't know
> > > what the directory structure is
Ok - here it is.
Satish
(lldb) p *nlist
error: Couldn't apply expression side effects : Couldn't dematerialize a result
variable: couldn't read its memory
(lldb) v
(char **) stringp = 0x7ffeefbfdfe8
(size_t) size = 16
(int) stopmap = 1
(const char *) prefix = 0x
(int) flags =
On Tue, 7 Mar 2023, Paul Smith wrote:
> On Wed, 2023-03-08 at 00:13 +, Martin Dorey wrote:
> > ... and it's sliced off half the gl_pathv pointer through calling an
> > implementation of glob that wasn't compatible with the declaration of
> > the structure that Make is using?
>
> Well, since t
On Wed, 2023-03-08 at 00:13 +, Martin Dorey wrote:
> ... and it's sliced off half the gl_pathv pointer through calling an
> implementation of glob that wasn't compatible with the declaration of
> the structure that Make is using?
Well, since this is a MacOS system we SHOULD be using our own
im
Is it possible that suspiciously half null pointer came from:
https://git.savannah.gnu.org/cgit/make.git/tree/src/read.c#n3480
nlist = (const char **)gl.gl_pathv;
... and it's sliced off half the gl_pathv pointer through calling an
implementation of glob that wasn't compatible with
On Tue, 2023-03-07 at 17:54 -0600, Satish Balay wrote:
> (lldb) p nlist[i]
> error: Couldn't apply expression side effects : Couldn't
> dematerialize a result variable: couldn't read its memory
Boy I really really dislike lldb as a tool. Does it work to install
gdb with brew instead? Not sure if
[rebuilt make with CFLAGS=-g]
Here is the gdb log
Satish
balay@ypro ~ % sudo lldb ./make-4.4.1/make
(lldb) target create "./make-4.4.1/make"
Current executable set to '/Users/balay/make-4.4.1/make' (x86_64).
(lldb) r
Process 54199 launched: '/Users/balay/make-4.4.1/make' (x86_64)
Process 5
On Tue, 2023-03-07 at 17:38 -0600, Satish Balay via Bug reports and
discussion for GNU make wrote:
> -> 3535 NEWELT (concat (2, prefix, nlist[i]));
> 3536
> 3537 if (globme)
> 3538 globfree (&gl);
> Target 0: (make) stopped.
> (lldb) bt
> * thread #1, queue = 'com.
Sorry - was a bit lazy - posted the stack trace from an earlier iteration where
the test makefile has some more stuff [assumed it wouldn't make a difference
wrt stack trace.]
Satish
balay@ypro ~ % cat makefile
CONFIGDIR = ${PWD}/testdir/config
ifeq ($(wildcard ${PWD}/testdir/readme),)
What a great looking bug report. Tiny reproducer, clear range of things tried,
clear crash with an effort to debug it. But there's a problem. The stack
trace includes:
frame #7: 0x000196b1 make`variable_expand_string(line="",
string="$(wildcard $(PETSCCONFIGDIR)/gmakegentest.py)"
This is likely a bug with this old version of macos/xcode. (sending in this
email to report this issue)
This test works fine with:
- default MacOS /usr/bin/make
- brew make-4.4.1
- gnumake-4.2.1 compiled with xcode clang (version below)
- gnumake-4.4.1 compiled with brew gcc (tried version 11)
-
11 matches
Mail list logo
