GNU make error code (e = -1) - makefile

I have a strange problem. I have been previously using GNU make for the last 4 weeks with no issues. I'm pointing my make file to an avr toolchain to cross compile for an ATMEL processor. A few days ago, GNU make stopped working. When I run make I get the following output:
make (e=-1): Error -1
make: *** [main.o] Error -1
To try and get more insight to the problem, I ran the code with just the echo output using make -n. It prints all of the statements in the makefile, including the commands. A short snippet of this output is as follows:
echo
echo "=================================="
echo "Compiling: " main.c
echo "=================================="
"/c/Users/Shane Reynolds/Documents/CDU_embeddedSystems/CDUEmbeddedToolbox/avr_tools/bin/avr-gcc" -c -std=gnu99 -g -mmcu=atmega1281 -DF_CPU=16000000UL -Wall -Wstrict-prototypes -Os main.c -o main.o
You can see that the command is printed at the end of this short snippet of the output. If I copy and paste the command into the terminal then the process works fine - but doing this every time is annoying. To try and understand why GNU make was failing I ran the debug tag make -d and received a lot of output. The snippet of what I think is important is:
CreateProcess(C:\Users\Shane Reynolds\Documents\CDU_embeddedSystems\CDUEmbeddedToolbox\avr_tools\utils\bin\echo.exe,echo,...)
Putting child 0x0043fdf0 (main.o) PID 4486808 on the chain.
Live child 0x0043fdf0 (main.o) PID 4486808
Main thread handle = 0x000000a8
Reaping winning child 0x0043fdf0 PID 4486808
Live child 0x0043fdf0 (main.o) PID 4488168
Reaping losing child 0x0043fdf0 PID 4488168
make (e=-1): Error -1
make: *** [main.o] Error -1
Removing child 0x0043fdf0 PID 4488168 from chain.
Can anyone help me with this? I've spent a couple of days trying to figure this out. I really hope that it is not something glaringly obvious, or simple.
EDIT: to add a little bit more background, I am using this on Windows 8 - when I run make from either bash or cmd I get the same error message. The link to my makefile is:
https://pastebin.com/j7uMSLic
FURTHER EDIT: I've created a very simple makefile with a very simple source code - running this produces the same error, but I can use the AVR toolchain to compile and link manually just like the previous case.

Okay.
So it turns out that it was something to do with Git bash (the terminal that I was using). Somewhere, somehow, I think one of the path variables got messed up. I completely uninstalled Git, and then re-installed and it works fine now. Not sure how this happened, but am glad to have it fixed.
If anyone else has an explanation, or can add more insight to the problem and how it can be avoided then feel free to post below.

Related

make[1]: Nothing to be done for error problem

after make's Makefile did flawlessly and next it was renamed to Makefile_
then it's run by the exact command but being inserted with:
-f Makefile
so now
make -f Makefile_ (... the rest identical),
then went out to give :
make[1]: Nothing to be done for 'all'
How'd it mean and be solved ?
Makefiles are intelligent and only compile or recompile when necessary, for example if a change in the files has been detected.
So if you've altered your code and then ran your Makefile, it will compile the corresponding code. But if you run it again without changing anything, it will give you an error message saying that there isn't anything to be done.
Thus the message:
make[1]: Nothing to be done for 'all'
If you want to avoid this, you can change a small part of your code just to recompile it or use the -B flag to force a remake.
With the -B flag, the command would be:
make -f Makefile_ -B

makefile recursive -q mode Error 1

I am trying to run a recursive invocation of "question mode", and I get an error in a very unique scenario.
I am using MAKE 3.81, and this has been tested on two completely separate environments.
I call "make -q", then that makefile calls "$(MAKE) -C sub/a/", then that makefile calls "$(MAKE) -f ../../makefile.b"
The testcase is as simple as I can make it. Can someone tell me why I get this error:
nachum:/home/nachum/makefile_bug[1497]$make -q
make -C sub/a
make[1]: Entering directory `/home/nachum/makefile_bug/sub/a'
make -f ../../makefile.b
make[1]: *** [b] Error 1
make[1]: Leaving directory `/home/nachum/makefile_bug/sub/a'
make: *** [a] Error 2
nachum:/home/nachum/makefile_bug[1498]$
Here are the makefiles:
makefile:
a:
$(MAKE) -C sub/a
sub/a/makefile:
b:
$(MAKE) -f ../../makefile.b
makefile.b:
all:
echo hi
The whole point of this exercise is to be able to check if sub projects need to be recompiled so I can properly build the top level project when necessary. Otherwise I have to use timestamps for everything. (I previously used timestamps, but I realized that caused extra confusion for other things.)
There are some weird workarounds for this problem. For example, if the recipe for a (in makefile) has an additional line above the call to $(MAKE), ie:
makefile:
a:
#echo hi
$(MAKE) -C sub/a
The problem goes away, AND the dependencies (in my full testcase) still work. Also using make directly seems to change the behavior (as opposed to $(MAKE)).
Any help would be appreciated.
Thanks,
Nachum
Your problem is roaming around the -q option specified. -q would run no command but give exit status if up to date. When you use ${MAKE} make -q -C sub/a is executed. after little permutation and combination I found that we can't use -q with -C option. If you want quite then use make --quite or if you just want to check the timestamps then try with -t (touch but don't compile) or '-n` (dry run).

OCAML compilation error Out_of_memory

when I compile on my mutualized server the source of last version of OCaml ocaml-4.00.0, I have the following Out_of_memory error message:
"
Fatal error: exception Out_of_memory
Exit code 2 while executing this command:
../ocamlcomp.sh -c -g -warn-error A -w a -I camlp4/boot -I camlp4 -I stdlib -o camlp4/boot/camlp4boot.cmo camlp4/boot/camlp4boot.ml"
my initial bash command is : make world
Would anyody have an idea where this error might come from?
Thanks
I've compiled OCaml 4.00.0 many times recently, and I have some saved logs. The exact failing command you give here appears at around the halfway point in the logs, which then go on to build the compiler successfully. I would conclude from this that you're actually running out of memory. I.e., that the compilation takes more memory than your system has available. Is this possible? (I don't know what you mean by a mutualized server.)

executing commands inside makefile

I'm executing the following command inside my makefile. It's giving me an error when I have to open file2. In other words, if there are any changes in file1.c based on the switches I select, the make fails exactly at this line.
unifdef -DSW1 -DSW2 -USW3 file1.c >file2.c
Okay, unifdef is an utility that does partial preprocessing for me. file1.c is input to unifdef and file2.c is output. My makefile is plain and simple and I don't have any dependencies to either file1.c or file2.c. Makefile dependencies are working out okay.
Thanks,
By default unifdef exits with status code 1 if it makes any changes to the input file. Make treats this as a failure. You can tell make to ignore the exit status by prefixing the command with a -
Version 2.7 of unifdef (which was released in March 2013) has a -x option to control the exit status logic, so it plays more nicely with make. You might want to use -x1 so that make will ensure that unifdef did actually make changes. See http://dotat.at/prog/unifdef/

How do I force make/GCC to show me the commands?

I'm trying to debug a compilation problem, but I cannot seem to get GCC (or maybe it is make??) to show me the actual compiler and linker commands it is executing.
Here is the output I am seeing:
CCLD libvirt_parthelper
libvirt_parthelper-parthelper.o: In function `main':
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:102: undefined reference to `ped_device_get'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:116: undefined reference to `ped_disk_new'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:122: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
collect2: ld returned 1 exit status
make[3]: *** [libvirt_parthelper] Error 1
What I want to see should be similar to this:
$ make
gcc -Wall -c -o main.o main.c
gcc -Wall -c -o hello_fn.o hello_fn.c
gcc main.o hello_fn.o -o main
Notice how this example has the complete gcc command displayed. The above example merely shows things like "CCLD libvirt_parthelper". I'm not sure how to control this behavior.
To invoke a dry run:
make -n
This will show what make is attempting to do.
Build system independent method
make SHELL='sh -x'
is another option. Sample Makefile:
a:
#echo a
Output:
+ echo a
a
This sets the special SHELL variable for make, and -x tells sh to print the expanded line before executing it.
One advantage over -n is that is actually runs the commands. I have found that for some projects (e.g. Linux kernel) that -n may stop running much earlier than usual probably because of dependency problems.
One downside of this method is that you have to ensure that the shell that will be used is sh, which is the default one used by Make as they are POSIX, but could be changed with the SHELL make variable.
Doing sh -v would be cool as well, but Dash 0.5.7 (Ubuntu 14.04 sh) ignores for -c commands (which seems to be how make uses it) so it doesn't do anything.
make -p will also interest you, which prints the values of set variables.
CMake generated Makefiles always support VERBOSE=1
As in:
mkdir build
cd build
cmake ..
make VERBOSE=1
Dedicated question at: Using CMake with GNU Make: How can I see the exact commands?
Library makefiles, which are generated by autotools (the ./configure you have to issue) often have a verbose option, so basically, using make VERBOSE=1 or make V=1 should give you the full commands.
But this depends on how the makefile was generated.
The -d option might help, but it will give you an extremely long output.
Since GNU Make version 4.0, the --trace argument is a nice way to tell what and why a makefile do, outputing lines like:
makefile:8: target 'foo.o' does not exist
or
makefile:12: update target 'foo' due to: bar
Use make V=1
Other suggestions here:
make VERBOSE=1 - did not work at least from my trials.
make -n - displays only logical operation, not command line being executed. E.g. CC source.cpp
make --debug=j - works as well, but might also enable multi threaded building, causing extra output.
I like to use:
make --debug=j
https://linux.die.net/man/1/make
--debug[=FLAGS]
Print debugging information in addition to normal processing. If the FLAGS are omitted, then the behavior is the same as if -d was specified. FLAGS may be a for all debugging output (same as using -d), b for basic debugging, v for more verbose basic debugging, i for showing implicit rules, j for details on invocation of commands, and m for debugging while remaking makefiles.
Depending on your automake version, you can also use this:
make AM_DEFAULT_VERBOSITY=1
Reference: AM_DEFAULT_VERBOSITY
Note: I added this answer since V=1 did not work for me.
In case you want to see all commands (including the compiled ones) of the default target run:
make --always-make --dry-run
make -Bn
show commands executed the next run of make:
make --dry-run
make -n
You are free to choose a target other than the default in this example.

Resources