Linux and GNU c++: Linking static libraries to shared object libraries

Linux and GNU c++: Linking static libraries to shared object libraries

Kevin Adrian

Member #7,087

April 2006

Hey guys,

I have some issues with loading Linux shared objects depending on static libraries.

First I have written a static library project called "atom" which generates the binary libatom.a.

Second I created another static library project which uses classes from "atom" and generates file libboson.a.

Both static libraries, libatom.a and libboson.a, are then linked to a Linux shared object library called "boson.so" (which I implemented myself, as well).

When I load this *.so file in an application via function "dlopen("path/to/so_file.so",RTLD_LAZY)" it happens that some classes or methods from libatom.a are not found. In this case I get a symbol lookup error message such as:

"undefined symbol: _ZN3gsb3env5scene9universe_IdE4initEv".

Note, that not all classes and methods of libatom are affected. It actually happens only with one class "universe" which is declared and implemented as a template within namespaces "gsb::env::scene" in libatom.a. Its method "init" is called in libboson.a.

When I move the content of the "atom" library to "libboson" then everything works properly.

Does GNU c++ have difficulties in general which such chain linking as described above? Could this behavior be related to the flag "-fPIC" which is applied to all three: libatom.a, libboson.a and boson.so?

My mouth will speak words of wisdom; the utterance from my heart will give understanding. (Psalm 49:3)

DanielH

Member #934

January 2001

Were you linking to libatom.a and libboson.a and in the proper order?

YouTube Coding Channel [www.youtube.com]

Kevin Adrian

Member #7,087

April 2006

I use " -latom -lgsboson"

My mouth will speak words of wisdom; the utterance from my heart will give understanding. (Psalm 49:3)

Edgar Reynaldo

Major Reynaldo

May 2007

Static linking should only be done on the resulting executable. If it's static, that means you can leave it un-linked until the end. Otherwise, you can get redefinition errors if more than one object is linked to it statically.

With gcc, you also have to watch out for link order. Sometimes you have to link the same library twice in the same command. For ex. gcc -Wall -Wextra -o proggy -I usr/local/include main.cpp -L usr/local/lib -loson.a -latom -lgsboson -latom

Also also, ar can be used instead of gcc if they are already object files.

If I was you I would just make a monolithic archive file and link it dynamically to a .so .

8-)

Eagle and Allegro 5 binaries [github.com] | Older Allegro 4 and 5 binaries [bitbucket.org] | Allegro 5 compile guide [members.allegro.cc]
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Kevin Adrian

Member #7,087

April 2006

I'll consider that. Thanks for your advice

Update I think I solved it. The problem was that the affected class is a template.

My mouth will speak words of wisdom; the utterance from my heart will give understanding. (Psalm 49:3)