Hi, sounds like a tough situation and printfs() might be the easiest but I
thought I might suggest one other complicated idea :-). Surely someone has
put together a cross-compiler for this os/hw combination? the idea of
compiling on-device would certainly have been impossibly slow until fairly
rece
On Sun, 2016-11-20 at 00:03 +0200, Jaak Ristioja wrote:
> So I guess I'll attempt to recompile glibc and run valgrind on the
> parent "make -j5" process and see whether that turns up anything. If
> not, then I'll try the -fsanitize=address approach. I expect all of this
> to take some time (and per
Hi!
On 13.11.2016 07:37, Tim Murphy wrote:
> Something like Valgrind might spot some initial problem that doesn't
> immediately crash but eventually spirals out of control.
I could try valgrind, but (1) I will need to recompile glibc with debug
symbols to use it, and (2) I don't have an eternity
With this change, users who have their editor misconfigured when writing
Makefiles without using 8 spaces for one TAB character will also get a
friendly error message.
I used the following 3 test cases:
echo -e "foo:\n echo bar" > broken.make
echo -e "foo:\necho bar" > broken.8.make
With this change, users who have their editor misconfigured when writing
Makefiles without using 8 spaces for one TAB character will also get a
friendly error message.
I used the following 3 test cases:
echo -e "foo:\n echo bar" > broken.make
echo -e "foo:\necho bar" > broken.8.make
