CODEWITHSUNDEEP
macoslinkerlinker-errors
Frank
Frank

Reputation: 4461

Link error on Mac OSX 10.6.7

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

Upvotes: 4

Views: 10499

Answers (1)

user405725
user405725

Reputation:

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.

Upvotes: 6

Related Questions