Brian,
the only thing that got "lost" was the tab before the recipe. Everything else
is as intended, I checked that.
Yes it is the nature of an SSCCE that it "does not make sense", that is
intentional, because the example is pared down to the smallest possible that
reproduces the problem.
Yes that means if I remove some characters from the path, even one character,
the problem does not happen.
This discussion is not about whether the code is good style or poor style. It
is not my code anyway and I don't have marching orders to change it.
This discussion is about the message from GNU Make that says "segmentation
fault", which I take it means, for sure, GNU Make has a bug - regardless of how
ugly the makefile code may be, or even erroneous. Please correct me if I am
wrong on this one.
I already found a "workaround" in my case, that is not the point. The point is
that there is a bug that IMHO should be fixed. I tried to zero in on it myself
but as I showed from the error messages, I have not gotten anywhere and to
investigate further I would have to study some things that I don't know, and it
would take me time that I don't have. So I am hoping there is someone here
that has more knowledge than me, and does not have to study and from the error
messages can get a pretty good idea exactly what is happening, right away.
Since it looks like I am in possession of the only system on which this does
crash, I am willing to edit the makefile any way you like and execute any
commands you want, so you can zero in on the bug.
But myself I reached the end of the time that I can devote to my own research
on this, given the knowledge I possess.
Mark
From: Brian Vandenberg <phantall+gnum...@gmail.com>
To:
Cc: Henrik Carlqvist <hc...@poolhem.se>; Mark Galeck <mark_gal...@pacbell.net>;
Martin Dorey <martin.do...@hds.com>; Paul D. Smith <psm...@gnu.org>; Boris
Kolpackov <bo...@kolpackov.net>; bug-make <bug-make@gnu.org>
Sent: Saturday, August 18, 2018 2:05 PM
Subject: Re: [bug #54529] [Makefile:5: foobar] Segmentation fault
I forgot to finish before hitting send.
I'm unable to reproduce this in RHEL6 with make 4.1 or Solaris 10 with
make 4.2.1.
Generally it's considered a bad idea / poor form to use
LD_LIBRARY_PATH. This could easily explain why we cannot reproduce
it. If you have something in that path that somehow causes this
problem, you're also the only one that could diagnose it.
Once you resolve this (or prove that using LD_LIBRARY_PATH is somehow
causing it), it would probably be worthwhile to find out why you find
yourself in need of LD_LIBRARY_PATH then find a better way to solve
that problem.
-brian
On Sat, Aug 18, 2018 at 2:52 PM, Brian Vandenberg
<phantall+gnum...@gmail.com> wrote:
>> OK, the only system for which this bugs actually shows up, is work build
>> server, and unfortunately, the IT guy does not know where the cores are, and
>> gdb is not working. Let me talk to him about fixing gdb and I will get back
>> to you what I find from it.
>
> This may depend on the distribution, but:
>
> cat /proc/sys/kernel/core_pattern
>
> The default tends contain the single word "core" with no extra frills
> (though if I'm wrong look in "man -s5 core" for info on deciphering
> the pattern it contains). Assuming it just says "core" then it should
> dump to whatever the current working directory is for the process
> that's dying.
>
> Additionally, the default is usually to have coredumps disabled. You
> can enable it in bash with:
>
> ulimit -c unlimited
>
>> The above Makefile is SSCCE for me - if I delete any elements from the above,
>> even just one letter from the echo string, does not happen.
>
> ... to include spaces, tabs and newlines? What about changing the
> path that was being printed inside $(shell)?
>
> You may want to see if you can come up with a variant on this crash
> that doesn't involve characters that may change in an email. For
> example, this looks strange:
>
> (...) | sed s/t/t}
>
> ... and makes me suspect something was lost in transliteration.
>
> -brian
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
