8

I am using GNU Make to build a C/C++ project that many people will use. The makefile attempts to be general because there are many optional files in this project and each user selects those files through a MATLAB interface which are then provided to the makefile via command line arguments (make target OPTS='XYZ' etc...).

When I use the makefile it correctly identifies the correct object dependencies, then proceeds to find the source prerequisites for those objects and build them. However, every time it tries to execute an object rule I get an error saying "Abort trap: 6" right after the gcc call.

The Makefile is as follows

vpath %.c $(PATH) $(OBJ_DIR)
# Pick compilers
CC1=g++
CC2=gcc
LNK=g++
# Assign variables for c/cpp implicit rules
CXXFLAGS= $(CCFLAGS) $(DEFINES) $(INCLUDES)
CFLAGS = $(CCFLAGS) $(DEFINES) $(INCLUDES)

# Assign various user-defined values
OUTPUT = -o $(USER_LIB)
C_OBJECTS = $(patsubst %.c,$(OBJ_DIR)/%.o,$(C_SOURCES))
CPP_OBJECTS = $(patsubst %.cpp,$(OBJ_DIR)/%.o,$(CPP_SOURCES))
OBJECTS = $(C_OBJECTS) $(CPP_OBJECTS) $(SIM_OBJECTS)

# User Library Dependencies and Compilation Rules
$(USER_LIB): $(OBJECTS)
    $(LNK) $(LINKERFLAGS) $(CCFLAGS) $(DEFINES) $(INCLUDES) $(OUTPUT) $(OBJECTS)

$(OBJ_DIR)/%.o: %.c 
    $(CC2) $(CFLAGS) -c -o $@ $<

and an example of what I get is:

gcc -g -D(the defines)  -I(all the includes) -c -o obj1/xyz.o ../common/xyz.c
make: *** [obj1/xyz.o] Abort trap: 6

However if I take that EXACT same gcc call and run it on the command line (just copy and paste) the file is correctly compiled and the object file placed in the obj1 folder.

I tried to look at 'make -d' to see if I could find anything either. Since that output is crazy long, the gist of it is the following:

... output truncated for brevity ...
gcc -g -D(the defines)  -I(all the includes) -c -o obj1/xyz.o ../common/xyz.c
Putting child 0x104f13cc0 (obj1/xyz.o) PID 24557 on the chain.
Live child 0x104f13cc0 (obj1/xyz.o) PID 24557 
Reaping losing child 0x104f13cc0 PID 24557 
make: *** [obj1/xyz.o] Abort trap: 6
Removing child 0x104f13cc0 PID 24557 from chain.

at which point the output ends. I also tried running make -k to see what happens after the first error. Every single source file produces the same result. Again, each source file is compilable with the exact call that make uses when done independently.

I'm completely lost on this one at this point and theres very little information about what "Abort trap: 6" means in this context.

I am running Mac OSX 10.7 with gcc-4.2 installed through Xcode.

I realize there isn't a rule for .cpp files currently, I do not at present have any .cpp source files to compile, though in the future there likely will be which is why there is support structure for it so far.

Thank you in advance for anyone who can help me.

EDIT: Added one proceeding line from the "make -d" output. EDIT: Added solution (moved to an answer)

Alex Buck
  • 197
  • 2
  • 2
  • 10
  • I've never run into an error like that before. Do we know for sure the error is coming from `make`? That is, are we sure `make` isn't passing along an error that is actually generated by gcc or by a subshell? – Mike Sherrill 'Cat Recall' Feb 21 '13 at 22:06
  • Hi! How would I investigate that? I know that GCC on its own produces no errors when I call it from the command line. I don't know how to check if its from a subshell as you put it. – Alex Buck Feb 21 '13 at 22:15
  • I Googled `OS x "gnu make" "abort trap: 6"`, and found a number of things related to Xcode, OS upgrades, etc. Do you get the same error if you start with `make clean`? (Assuming you have a phony target named "clean".) – Mike Sherrill 'Cat Recall' Feb 21 '13 at 22:29
  • I have a .PHONY target clean and all it does is "rm -rf $(OBJ_DIR) and rm -rf $(USER_LIB)" basically it clears away any created objects or targets libs. And no, if I call "make clean" I do not get an error. I have written successful makefiles on this system before (if that was the concern) so I know the make system does work as of yesterday. – Alex Buck Feb 21 '13 at 22:36
  • Try removing '-o obj1/xyz.o' from your gcc line. – Peter L. Feb 21 '13 at 23:14
  • Removing the output flag from gcc in the makefile (i.e. removing -o $@) doesn't change anything. If you meant from the standalone gcc call, it still works without it but the output is just in the current directory instead of the obj1 directory. – Alex Buck Feb 22 '13 at 00:20
  • I might not have asked my question clearly. Do you still get the error if you run `make clean`, and *then* run `make`? – Mike Sherrill 'Cat Recall' Feb 22 '13 at 00:37
  • Ah, apologies for the misunderstanding. Yes I still get the error after calling 'make clean' and then running 'make'. And thank you for the interest in helping! – Alex Buck Feb 22 '13 at 00:45
  • 11
    This message tells you that the command make executed (gcc in this case) exited with a non-success result. In this case, "Abort trap: 6" is MacOS's way of telling you that gcc failed due to a SIGABRT signal (which is signal #6). Usually this would also mean a core dump but you don't have one (make would tell you if you did). The question is why is GCC failing when run from the makefile but not from the command line. It's likely due to an environment difference. I recommend changing the gcc call to add the "-v" (verbose) option, try it both ways, and see if there's a difference. – MadScientist Feb 22 '13 at 13:05
  • @MadScientist Thank You!! You response got me thinking. I add a variable $(PATH) to the vpath, however that is NOT intended to by my system path, it is a command line input I provide with paths to the numerous source files. It appears make is not interpreting it how I intended. Simply changing the variable in vpath line to $(SRC_PATH) instead of $(PATH) fixed my issue! As a side note I did also (after this) try -v compile, and on the command line I got the expected result, nothing strange. However from make it didn't output verbose information at all, so theres nothing to compare to. – Alex Buck Feb 22 '13 at 13:54
  • @MadScientist: Where id you look up that a SIGABRT signal is signal 6 – Casebash Jul 04 '14 at 06:48
  • There are many places. Search Google for SIGABRT. Or in bash you can run `kill -l` to get a list of all the signals and their numbers. – MadScientist Jul 04 '14 at 16:00

2 Answers2

5

With help, answered my own question. SOLVED: First see @MadScientist's comment for what "Abort trap: 6" is.

Given that clue I realized I use a variable that could be confused with a system variable, $(PATH). It appears Make was not interpreting the following line how I expected it:

vpath %.c $(PATH) $(OBJ_DIR)                        <------ Bad

It looks like there is some interference with the system variable $(PATH) which may have been causing problems. Simply changing the vpath variable to $(SRC_PATH) eliminates the conflict with the system variable and any potential interference, thus fixing the problem.

vpath %.c $(SRC_PATH) $(OBJ_DIR)                    <------ Good

Lesson Learned: Be careful with variable names and know what your environment variables are.

Credit to @MadScientist for pointing out what "Abort trap: 6" means and suggesting environment issues.

Alex Buck
  • 197
  • 2
  • 2
  • 10
0

if there is an assert method in your code you can get that error (abort trap : 6).

for example:

assert(numberOfItems >= 0);

and if the 

numberOfItems < 0

you will get such an error when you call the makefile

Erdem Meral
  • 23
  • 4