bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault


From: Mark Galeck
Subject: Re: [bug #54529] [Makefile:5: foobar] Segmentation fault
Date: Tue, 21 Aug 2018 06:37:05 +0000 (UTC)

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 <address@hidden>
To: Henrik Carlqvist <address@hidden>; Mark Galeck <address@hidden>; Paul D. Smith <address@hidden>; Martin Dorey <address@hidden>; address@hidden; address@hidden
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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]