shared-libraries

I have the following layout: top_project + subproject1 + subproject2 Each of subproject1 and subproject2 creates a static library. I would like to link these static libraries in a single shared library at the top_project level. The information I gathered so far is: Either compile using -fPic (necessary on everything but Windows) in order to create position-independent code which will allow linking the static libraries into a single shared library or decompress all static libraries (e.g. using ar ) and re-link them into a shared library (which I think is an inelegant & non-portable solution)

I'm trying to compile my program to a shared library that I can use from within Python code using ctypes. The library compiles fine using this command: g++ -shared -Wl,-soname,mylib -O3 -o mylib.so -fPIC [files] `pkg-config --libs --cflags opencv` However, when I try and import it using ctypes from ctypes import * mylib = CDLL("/path/to/mylib.so") print mylib.test() // Expected output: Hello World I get the following error: libdc1394 error: Failed to initialize libdc1394 What's going on? Very frustrating that nobody actually shows a concrete solution. I had this issue after installing OpenCV.

I know an .so file is a kind of dynamic library (lots of threads can share such libraries so there is no need to have more than one copy of it in memory). But what is the difference between .a and .la ? Are these all static libraries? If dynamic libs have big advantages over static ones, why there are still lots of static libraries? I also want to know the underlying mechanism to load libraries (both kinds) and how a piece of code in a lib is invoked when it is used somewhere. Which part of the kernel should I study? And what related Linux command/utility should I know in order to know how a

I have a shared library that is compiled as 32-bit. Can I use it from a 64-bit application or do I need to compile the shared library as 64-bit as well? No, you cannot load a 32-bit library in a 64-bit application through conventional means. There are some clever hacks out there such as having a 32-bit application which loads the library and exports the functions through an IPC interface, but if you have the option to compile the library as 64-bit, then that is by far the best choice. cdiggins You cannot load dynamically or statically a 32-bit library from a 64-bit application or vice versa.

I have to compile a program on a current ubuntu (12.04). This program should then run on a cluster using CentOS with an older Kernel (2.6.18). I cannot compile on the cluster directly, unfortunately. If I just compile and copy the program without any changes I get the error message "kernel too old". The way I understood it, the reason for this is not so much the Kernel version, but the version of libc that was used for compilation. So I tried to compile my program dynamically linking the libc from the cluster and statically linking everything else. Research There are already a lot of questions

the title of this question is an exact dupe , but the answers in that question don't help me. I have a bunch of object files packed in a static library: % g++ -std=c++98 -fpic -g -O1 -c -o foo.o foo.cpp % g++ -std=c++98 -fpic -g -O1 -c -o bar.o bar.cpp % ar -rc libsome.a foo.o bar.o I'd like to generate libsome.so from libsome.a instead of the object files, but the library is really barebones: % g++ -std=c++98 -fpic -g -O1 -shared -o libsome.so libsome.a % nm -DC libsome.so 0000xxxx A _DYNAMIC 0000xxxx A _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 0000xxxx A __bss_start w __cxa_finalize