Question

I’m seeing:

ld: in objs/AttributeValueTest.o, can't link with a main executable for architecture x86_64

When building a very simple program which has only 1 .h and 1 .cpp file.

The compile lines are:

g++ -g -I./ -I/usr/local/include -o objs/AttributeValueTest.o tp_datastruct/tests/AttributeValueTest.cpp -L/usr/local/lib -lavrocpp -lcppunit -lm 
g++ -g -I./ -I/usr/local/include -o AttributeValueTest objs/AttributeValueTest.o -L/usr/local/lib -lavrocpp -lcppunit -lm 

I tried to specify -arch x86_64, -arch i386 and -m32, but nothing worked (I got other errors, it was complaining that libcppunit was not in the right format).

Any idea/pointer/suggestion?

Thanks!

---

Very strange. I did some digging around, and saw somewhere that AttributeValueTest.o might be an executable already. I did a “file” on that AttributeValueTest.o, and sure enough, it is a ready-to-go executable. I modified my makefile to rename that .o into AttributeValueTest, and I can happily run it. Also, the executable comes with a “.dSYM” directory, which I can remove without any problem… I don’t understand what is going on, but I can run my executable now…

Answer 1

You forgot to specify -c option to the g++ to compile a source code into object file. So it is getting compiled and linked into executable file. Then you are trying to link executable into executable, which fails. From the gcc‘s manual page:

-c Compile or assemble the source files, but do not link. The
linking stage simply is not done. The
ultimate output is in the form of an
object file for each source file.

By default, the object file name for a source file is made by
r> eplacing the suffix .c, .i, .s, etc.,
with .o. Unrecognized input files, not
requiring compilation or assembly, are
ignored.