I've written some code (static library) in c++, with (i think so, C compatiblity - got 'extern C' and so on), and then i wanted to use it in my C application.
When im runing my C app, i got error:
undefined symbol: _ZTISt9exception
c++ code was compiled with gcc with : -std=c++0x -lstdc++ flags
then, on obj files i run ar
i suppose that symbol comes direct from c++ library. When im compiling my C app I of course add my C++ lib in my makefile, and compilation finishes with no error.
What might be wrong ?
thx for all help
A static library is not linked, it is just a collection of object files in an archive. All files names like libxxx.a are static libraries, while files named like libyyy.so are dynamic libraries.
This means that the the external symbols in your library are never resolved until you link with it to make an executable. Then you need all the library files needed by your library as well.
You'll need to link the final executable with the C++ runtime library (-lstdc++); it has no effect when compiling the C++ objects, only linking the executable.
Related
I don't quite understand how the compilation of a library that uses another library work. From what I understand the is 4 cases :
1) Compiling a static library (A) that uses a static library (B) : The compilation would work, but linking against library A would not work because a static library is just an archive containing the .o files resulting from the compilation of A, and not from B. Is it true that when creating a static library, the compilation phase searches for function definition and find them in the header. At the linking phase, the compiler searches for function implementations in the library B and the compilation is successful if it finds them but it doesn't actually put the function implementations in the static library A. And that's why when linking against A it doesn't work
2) Compiling a static library that uses a dynamic library : I think both the creation of A and the use of A would work, but why is that? What does the compiler actually put in the dlls/so?
3) Compiling a dynamic library that uses a static library : Would this work?
4) Compiling a dynamic library that uses another dynamic library : Would this work too?
Thanks for your time.
If you create a library or program in C or C++, the build process consists of two steps:
Compiling each C/C++ file into an object file
Linking the object files and creating library or executable (If you create a static library, it isn't really linking; but let's use this word for simplicity.)
Compliation
If you compile code that makes use of a library, you need header files (.h) for the library. They declare the public functions and classes in the library. You don't need to binary files for compilation.
Linking
For the linking step, you then need the binary file of the static or dynamic library (.lib or .a for static libraries, .dll or .so for dynamic libraries).
Dependencies between libraries
If you create a static library, all your object files will be put into a new library file. Nothing from the consumed library (static or dynamic) will be included. But it will be needed when somebody uses your library. So your library isn't self contained.
If you create a dynamic library and consume a static library, the necessary code from the static library will be included into your dynamic library. The new dynamic library will be self contained as far as the consumed library is concerned.
If you create a dynamic library and consume a dynamic library, only a reference to the consumed library will be included. So to run the final product, both the new and the consumed library will need to be available.
I have a C++ project and I am linking to an external library (using all of its headers and source files). I did this by going into the project configuration and adding the source.a library that i wanted to link to. Now my question is how do I know if my library is linked to my program statically or dynamically. I have read numerous thread about the types of linking however i am still not sure about the type of linking I have. Any suggestions on this regard would be helpful
I did this by going into the project configuration and adding the source.a library...
It's static. If it were dynamic you would have added a .dylib file instead (which apparently you don't have one of).
I wrote a static library (compiled with TDM-gcc 4.8.1 in Windows 7 for x64) that has dependencies on other static libraries. Boost libraries (locale and system) to be specific.
Since I'm building a static library I assumed that the libraries I'm dependend on would automatically included in my final .a, especially since I'm using them in my code.
But when I'm trying to build an executable that statically links to my aforementioned library there are still undefined references to some boost parts, that are definitely used in my library.
Is there a way to fix that?
Any help is gladly appreciated. Thank you
Edit:
I haven't been careful enough, because I now know what causes the problem. I'm using codeblocks and all the necessary arguments for building the archive are declared in the project prooperties. But codeblocks doesn't even call the linker when building my library. Instead it calls ar.exe and passes all object files of my project. That way, no external library are ever included. So, I have too look for away to tell codeblocks to build the library in the right way..
Your executable needs to link against all the relevant libraries, including the ones it directly depends on, plus the ones it indirectly depends on. When you link a static library you typically do not embed other static libraries within it.
Let's say I have a C++ library code, with some definitions wrapped with extern "C" { ... }.
I also have a C library code which uses that C++ library.
What I want to do is to create a single .so file, so that only one call to dlopen should be enough to start using this library.
Here's what I do now: I'm first compiling my C++ library to a .so file with -shared -rdynamic -fPIC. Then I'm compiling my C library to a .so file with same parameters. After that, I have to load C++ library with dload before loading the C library. Otherwise loading fails with a undefined symbol error.
What I want to do is to compile this two libraries into one .so file so that only one call to dload should be enough to use it.
How can I do that?
Thanks in advance.
EDIT: Compiling to .o files and then combining doesn't work for me. Here's what I do:
I compile each file to object file with -fPIC parameter
I link them with clang [list of object files] -shared -rdynamic -fPIC -o libmylib.so
When I try to load, I get undefined symbol: __gxx_personality_v0 error.
EDIT2: Ahh, I forgoto to link it against libstdc++, it works now. Thanks.
The easiest way is to combine them into a single .so file by either combining all object files, or building two static .a libraries and then linking them into a single shared library.
If you really want to keep two .so files, link the first library to the second, as you would with executable. E.g. if libfoo depends on libbar, compile libfoo with -lbar. You'd have to have the dependent libraries in your default library path or in LD_LIBRARY_PATH environment variable.
I have been building a static library on Linux. So far it is purely self contained and all code inside does not use anything other than the standard library. I have recently made a change and now some compilation units are using boost code. I have been building the library using the following:
g++ -c -Wall -pedantic *.cpp
ar -cvq libbfclass.a *.o
My question is this: is it necessary for me to adapt this method to deal with the use of the new libraries or will I just need to provide the link library when building the executable that uses my own library? From what I understand a static library is basically just an archive of object files, but I was wondering if I need to modify my build scripts in order to make everything work as it should, or if it is only necessary when building executables???
You are correct - a static library is just an archive of object files. Symbols are resolved when you compile the final executable, so that's when you need to provide the references to the other libraries.