views:

44

answers:

1

Hi,

I am building a C++ project in XCode which uses two libraries. Say for e.g libX.a and libY.a. There are some function definitions common on libX.a and libY.a for which I get duplicate symbol linker error.

This is fine, but I get only one error at a time. Once I fix the error, I'll get the next duplicate symbol error and this process repeats.

I have two problems with this approach:

  1. I don't have an exact count of the number of duplicate errors. I wanted to know all the duplicate symbols found. So that I can distribute the fixing of this between couple of developers.

  2. Fixing the error is fast enough compare to the time it takes to build the libraries and then link to generate the executable.

Is this possible? I mean is it possible by setting any flag so that the linker gives all the duplicate symbols at once.

EDIT: adding sample code for clarification: Let me show an example here:

test1.h

void foo()
{
}

void bar()
{
}

test2.h

void foo()
{
}

void bar()
{
}

test1.cpp

#include "test1.h"

void j() 
{
    foo();
    bar();
}

test2.cpp

#include "test2.h"

void k()
{
    foo();
    bar();
}

Compiling now:

g++ -c test1.cpp
g++ -c test2.cpp

Linking now:

g++ -o final test1.o test2.o

Even though there are 2 duplicate symbols foo and bar, I get the error only for foo as shown below:

ld: duplicate symbol foo()    in test2.o and test1.o
collect2: ld returned 1 exit status

Once I fix foo, then I get the error for bar shown below:

ld: duplicate symbol bar()    in test2.o and test1.o
collect2: ld returned 1 exit status

What I would like is getting these two errors at once. So that I fix all of them and then link at one shot.

Thanks

Best Regards, Marc

A: 

You can use the nm command to list all the symbols in the libraries, and sort and uniq -d to print the duplicates. Something like:

nm -j test1.o test2.o | sort | uniq -d

This will also list the undefined symbols they share in common. You can get a list of those with nm -u.

A bit of a hack, but it might get you there faster.

Karl Bielefeldt
thanks a lot :) that helped
Mark