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
>> 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