Using C/C++ static libraries from iPhone ObjectiveC Apps

Question

Is it possible to have a C static library API, which uses C++ internally and hide this from users of the library?

I have writen a portable C++ library I wish to statically link to an iPhone application.

I have created an Xcode project using the Max OS X 'static library' template, and copied the source across, as well as writing a C wapper (to deal with exceptions) using (extern "C").

I am trying to use the generated library (.a file) in another Cocoa iPhone application.

Everything works well if the I use (.mm) extentions on the calling ObjectiveC file and (.cpp) on the implementation class in the library.

But I get unresolved symbols on linking when I try and change the wrapper file to a (.c) extention, even though all the wrapper function files are only C functions.

Just becuase C++ is used internally in a library, does it mean that externally it still must be treated as a C++ program. Is there not anyway to enforce this abstraction?

Edit: Thanks for the replies,

I had been using extern "C", I was just unsure about what configurations where needed in the calling project. ie. if the calling projected would require to know if it used C++ or could be ignorant and think its a purely C library.

It would seem I cannot, and I must use (.mm) files on my ObjectiveC classes.

Answer 1

It's too hard to do this in comments, so I'm just going to demonstrate for you quickly what the linking issues are that you're having. When Xcode encounters files, it uses build rules based on the suffix to decide which compiler to use. By default, gcc links the files to the standard C library, but does not link with the standard C++ library. Archive files (static libraries) have no linking resolution done at all. They are basically an archive of object files which need to be linked. Since you have no .mm or .cpp files in your project, g++ is never called and your files are never linked to the standard libraries. To correct this, just add the standard C++ libraries to your other linker flags in your Xcode project, or just simply add them to the pre-defined other flags option as -l (e.g., -lstdc++).

Here is a quick demonstration:

stw.h:

#ifdef __cplusplus extern "C" #endif void show_the_world(void); 

stw.cpp:

#include <iostream> #include "stw.h" using namespace std;  extern "C" void show_the_world() {   cout << "Hello, world!\n"; } 

Build the library:

$ g++ -c stw.cpp -o stw.cpp -O0 -g $ ar rcs stw.a stw.o 

Using the library from a C application:

myapp.c:

#include "stw.h"  int main() {   show_the_world();   return 0; } 

Building the C application:

$ gcc -o myapp myapp.c stw.a -lstdc++ -g -O0 $ ./myapp Hello, world! $ 

If you try to compile without the -lstdc++ you will get all the unresolved issues because the C compiler has absolutely NO idea that it should link to the C++ runtime (and why would it, right!?!?) so you have to add this manually. The other option you have is to change the build rule for your project... instead of having Xcode use gcc to build .c and .m files, tell it to use g++ and your issues will be resolved.

Answer 2

You should declare the functions you want to be visible extern "C". Their signatures need to be C-compatible, but the contents do not (you may access C++ objects, for instance, but you cannot pass them directly; pointers are okay). The symbols will then be visible to any C-compatible environment.

EDIT: And compile it as a C++ source file, C doesn't have the notion of language linkage. There are a couple other gotchas with language linkage (like the fact that all extern "C" functions with the same name are the same function, regardless of namespace).

EDIT2: In the header, you can check for the macro __cplusplus, and use that to set for C++ and other languages, respectively (because C++ will require extern "C" declarations, and other languages will probably complain about them).