Failing to link with static library

[c0d1f1ed]

Hi all,

I have a compiled static library (*.a file) with its interface defined in interface.h and now I simple want to call a few functions of it:

#include "interface.h"

int main(int argc, char * const argv[])
{
Object *object = constructObject();
destructObject(object);

return 0;
}

But even though I added the static library to the Xcode project, it fails to link, telling me _constructObject and _destructObject are undefined. It might be worth noting that the library is mainly written in C++, but it should have a C interface using extern "C". It works fine in Windows with Visual C++.

Any ideas what could be wrong? How can I check whether Xcode really links with my library?

Thank!

c0d1f1ed

[akb825]

Look though the target and see if the library is present under the "Link Binary with Libraries" section.

[c0d1f1ed]

Look though the target and see if the library is present under the "Link Binary with Libraries" section.
Yes, it definitely is. So I really don't understand why this isn't working. Exactly the same thing on other platforms works fine.

[akb825]

You can try compiling it from the command line to make sure that it work that way. If it does, then you have your XCode project set up wrong. If it doesn't, you have another problem. (like perhaps you messed up when compiling the static library)

[c0d1f1ed]

I managed to get things to build correctly by compiling the application as a C++ file, and wrapping the interface.h file in extern "C".

I would like it to work with C applications though. But now I'm getting linker errors with (among other) undefined ___gxx_personality_v0. I googled for this and it looks like it has something to do with having different compiler versions. :???:

So clearly there must be some Xcode setting to make this work, right?

[akb825]

What you need to do is wrap interface.h with extern "C" (making sure you have #ifdef __cplusplus in there) and then build the static library, then build the application with the same header file. That way it knows to use C linkage (and not use C++ name mangling) when compiling both the library and test application.

[OneSadCookie]

The gxx_personality_v0 is usually caused by mixing GCC 4- and GCC 3-compiled C++ code.

The other errors sound like you don't understand how to use extern "C"...

[c0d1f1ed]

Thanks for the suggestions! I'm now using the same header file in both the library and application project (with __cplusplus guarding extern "C"), and I'm left with the following linker errors:

Tool:0: Undefined symbols:
Tool:0: collect2: ld returned 1 exit status
Tool:0: __ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostrea mIT_T0_ES7_RKSbIS4_S5_T1_E
Tool:0: __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamI T_T0_ES6_
Tool:0: __ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree _node_baseS0_RS_
Tool:0: __ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_n ode_baseRS_
Tool:0: __ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
Tool:0: __ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base
Tool:0: __ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
Tool:0: __ZSt17__throw_bad_allocv
Tool:0: __Znwm
Tool:0: __ZNSt19basic_ostringstreamIcSt11char_traitsIcESaI cEED1Ev
Tool:0: __ZNSt19basic_ostringstreamIcSt11char_traitsIcESaI cEEC1ESt13_Ios_Openmode
Tool:0: __ZNSt14basic_ofstreamIcSt11char_traitsIcEED1Ev
Tool:0: __ZNSt14basic_ofstreamIcSt11char_traitsIcEEC1EPKcS t13_Ios_Openmode
Tool:0: __ZNSspLERKSs
Tool:0: __ZNSspLEPKc
Tool:0: __ZNSsD1Ev
Tool:0: __ZNSsC1Ev
Tool:0: __ZNSsC1ERKSs
Tool:0: __ZNSsC1EPKcRKSaIcE
Tool:0: __ZNSs7reserveEm
Tool:0: __ZNSs6appendERKSs
Tool:0: __ZNSs6appendEPKcm
Tool:0: __ZNSolsEPFRSoS_E
Tool:0: __ZNSolsEj
Tool:0: __ZNSolsEf
Tool:0: __ZNSaIcED1Ev
Tool:0: __ZNSaIcEC1Ev
Tool:0: __ZNKSt19basic_ostringstreamIcSt11char_traitsIcESa IcEE3strEv
Tool:0: __ZNKSs4sizeEv
Tool:0: __Znam
Tool:0: __ZdlPv
Tool:0: __ZdaPv
Tool:0: ___cxa_pure_virtual
Tool:0: ___cxa_guard_release
Tool:0: ___cxa_guard_acquire
I disabled exceptions and I'm linking the standard libraries statically, but that doesn't help...

[OneSadCookie]

Try adding -lstdc++ to your linker flags.

This is probably now irrelevant: http://tips.onesadcookie.net/tips/published/C+Headers+and+C%2B%2B+Code

[c0d1f1ed]

Try adding -lstdc++ to your linker flags.
That works! What also worked was linking statically to the standard library instead of dynamically, for the application (previously I was only linking it statically for my library).

Is there any logical explanation for this behaviour?
This is probably now irrelevant: http://tips.onesadcookie.net/tips/published/C+Headers+and+C%2B%2B+Code
The code was working fine with other compilers, so I was fairly confident the use of extern "C" was already correct.

Thanks guys!

[OneSadCookie]

That works! What also worked was linking statically to the standard library instead of dynamically, for the application (previously I was only linking it statically for my library).

Is there any logical explanation for this behaviour?

Um, you don't ever have a choice whether to link to libstdc++ statically or dynamically... If you're using GCC 3, you must link statically, and if you're using GCC 4, you must link dynamically. The two are incompatible, so there's no chance to use GCC 3's libstdc++ with GCC 4 or vice versa.

It also makes no sense to link anything into a static library. Static libraries are not linked at all; they are just an archive of object files.

[c0d1f1ed]

I'm using the latest Xcode, which uses GCC 4.0. It offers me the option to link libstdc++ statically or dynamically. That's all I know. :ninja: