No problem, thank you for explaining. I still think that Make if it invokes a
program directly, and the program crashes, Make should say something that will
help the user understand it is not Make bug. There has to be a way to print a
more informative error message.
Does the error message as it is, is it not _exactly_ the same as if Make itself
crashed? If so, then how is the user to know, whether this is a bug or not?
By studying Make source? - this is a non-starter. I can't tell my users "hey,
if this happens, read Make source to find out if it is really Make bug".
From: Paul D. Smith <[email protected]>
To: Henrik Carlqvist <[email protected]>; Mark Galeck
<[email protected]>; Paul D. Smith <[email protected]>; Martin Dorey
<[email protected]>; [email protected]; [email protected]
Sent: Monday, August 20, 2018 11:33 AM
Subject: [bug #54529] [Makefile:5: foobar] Segmentation fault
Update of bug #54529 (project make):
Status: None => Not A Bug
Open/Closed: Open => Closed
_______________________________________________________
Follow-up Comment #4:
This message:
$ make-4.2.1/make
touch foobar
make: *** [Makefile:5: foobar] Segmentation fault (core dumped)
doesn't mean that make dumped core. If it had you'd not see the prefix
containing the make target name, etc.
This means that the program make invoked dumped core. Make is printing out
the results of invoking the program (specifically, the results of the
waitpid() call waiting for the child to complete). In this case, since this
is a simple command so make can invoke it directly without using the shell, it
means that the "touch" program dumped core.
I suspect that your attempt to modify the LD_LIBRARY_PATH has caused an
incompatible version of the C runtime library (libc) or similar to be loaded
when the "touch" program is running.
I can't explain your "delete any elements and it doesn't happen" result,
except of course that if you modify the pathname you are using with "echo",
then the value of the ROOT make variable will change and the LD_LIBRARY_PATH
value will be different and thus it may not find the wrong library.
I can't see any way this can be related to make so I'm closing this as "not a
bug" but if you have more information feel free to add it as a comment and I
can re-open.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?54529>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
