cmake 2.8
gcc (GCC) 4.8.1
Edit ----------
Wrapping the static libraries in whole-archive works for every library except the pjmedia-videodev The problem now is that when I try and build I get the following error.
cbar_factory_init': colorbar_dev.c:(.text+0x2a0): undefined reference to pjmedia_format_init_video'
Hello,
I have created a shared library and I need to link that library with about 10 static libraries. I then link my executable with the shared library.
My question is that when I run make it fails to link as it wants the static libraries as well. The purpose of is to create a wrapper for the static libraries. So the executable only has to link with 1 single shared library. As I am linking the shared library with the statics, then the statics will automatically become part of the source code of the shared library.
Only code sippnets to make it short.
In my CMakeLists.txt that creates the shared library and links the static libraries:
add_library(app_module_sip SHARED app_module_sip_init.c)
set(PJSIP_LIBRARIES
g7221codec
gsmcodec
ilbccodec
milenage
pj
pjlib-util
pjmedia
pjmedia-codec
pjmedia-audiodev
pjmedia-videodev
pjnath
pjsip
pjsip-simple
pjsip-ua
pjsua
portaudio
resample
speex
srtp
)
target_link_libraries(app_module_sip pthread m uuid nsl rt asound crypto ssl ${PJSIP_LIBRARIES})
Now my CMakeLists.txt that makes the executable
add_executable(app sip_test.c)
target_link_libraries(app app_module_sip)
Is this correct what I am doing here. I don't want to link the executable with the static libraries. Just the single shared library as that is my wrapper what I will be calling the functions in.
It does link ok, if I link all the statics libraries when making the executable, but that is not the result I want.
Many thanks for any suggestions,
I tried to test my solution but your CMakeLists.txt worked for me without any changes. Still, looking at this question:
Include static lib in dynamic lib,
it appears that you should try
target_link_libraries(app_module_sip ... ssl -Wl,-whole-archive ${PJSIP_LIBRARIES} -Wl,-no_whole-archive)
(scroll to the end, it's a long line)
It's not that simple.
You can look at using '-Wl,--whole-archive' or '-Wl,--export-all-symbols' depending on your platform, but there's no good cross platform way of doing this. Everything does it differently, and windows plays a completely different game using lib.exe.
You probably want to do something like this:
http://www.mail-archive.com/cmake#cmake.org/msg01890.html
...and add support specifically for the platforms you want to support, one at a time.
# Location for shared library
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/libs)
# Create shared library
add_library(app_module_sip SHARED app_module_sip_init.c)
# compile and link for 32 bit mode
set_target_properties(app_module_sip PROPERTIES COMPILE_FLAGS "-m32" LINK_FLAGS "-m32")
# PJSIP static libraries
set(PJSIP_LIBRARIES
pjsua
pjsip-ua
pjsip-simple
pjsip
pjmedia-codec
pjmedia-videodev
pjmedia
pjmedia-audiodev
pjnath
pjlib-util
resample
milenage
srtp
gsmcodec
speex
ilbccodec
g7221codec
portaudio
pj
)
# Wrap the static libraries in to the shared library
target_link_libraries(app_module_sip -Wl,--start-group ${PJSIP_LIBRARIES} -Wl,--end-group
m uuid nsl rt pthread asound crypto ssl)
Need to wrap the pjsip libraries will the following linker command -Wl,--start-group *.a -Wl,--end-group.
That solved my problem.
Related
(I saw answers of every single StOF questions regarding this - none fully helped. I'm very frustrated after trying so hard for 3 days & nights.)
libcurl.a is statically linked with:
OpenSSL 1.1.1k [64bit/32bit]
brotli 1.0.9 [64bit/32bit]
libgsasl 1.10.0 [64bit/32bit]
libidn2 2.3.1 [64bit/32bit]
libssh2 1.9.0 [64bit/32bit]
nghttp2 1.43.0 [64bit/32bit]
zlib 1.2.11 [64bit/32bit]
zstd 1.5.0 [64bit/32bit]
Case 1 - as if curl isn't statically linked
x86_64-w64-mingw32-gcc-10.2.0.exe -o main.exe main.c "C:\curl-7.77.0-win64-mingw\lib\libcurl.a" -DCURL_STATICLIB
Throws unending lines of error, as if libcurl isn't statically linked with its dependencies*:
...\lib\libcurl.a(http2.o):(.text+0x7f): undefined reference to `nghttp2_version'
...\lib\libcurl.a(http2.o):(.text+0x297): undefined reference to `nghttp2_submit_rst_stream'
... (then the errors include many more undefined reference to symbols from nghttp2, ssl, crypt, ssh, gsasl)
The best way to use libcurl is to get the necessary flags via pkg-config. In MSYS2 this works quite well. Otherwise you may need to point the environment variable PKG_CONFIG_PATH to the location of libcurl.pc.
On my system
pkg-config --define-prefix --static --libs libcurl
returns:
-LD:/Prog/winlibs64-11.1.0/custombuilt/lib -lcurl -lidn2 -lrtmp -lssh2 -lnettle
-lgnutls -ladvapi32 -lcrypt32 -lgss -lwldap32 -lzstd -lz -lws2_32 -lrtmp
Note that with MinGW the order of the libraries is also important. The library providing a symbol should be mention on the linker command line after the object that refers to that symbol.
Finally you need to make sure that each library you include was in fact built and used statically. With that I mean no stuff like __declspec(dllexport) may be used when building it, and no __declspec(dllimport) may be used when compiling anything that depends on it. For some libraries this may require specific defines before including the library's header(s).
Specifically for libcurl and nghttp2 I find that it helps to add the following at the top of lib/http2.c and lib/http.c when building libcurl:
#if defined(BUILDING_LIBCURL) && !defined(DLL_EXPORT)
#define NGHTTP2_STATICLIB
#endif
This will define NGHTTP2_STATICLIB when building static libcurl.
I have reported this as a bug at: https://github.com/curl/curl/issues/7353
It is so enormously saddening to see how many people have struggled and are still struggling to statically link libcurl to their program. So much so that a very active Curl maintainer said: "building static is a roller coaster left for the users to deal with on their own as its such a never-ending race for us to try to support."
Since linker is saying undefined references, then libcurl.a must be:
not statically linked
Or, you've got the sequence of libraries unarranged. Linker is sensitive to sequence. Example: If libbrotlidec-static.a needs a function/symbol which is inside libbrotlienc-static.a, then libbrotlienc-static.a must be mentioned before libbrotlidec-static.a
A static library is an archive .a of object .obj files. And they're not statically linked in themselves. That's why, to link some-static-library.a to a program, you need to collect and manually mention every.a single.a static.a library.a that are dependencies of some-static-library.a.
In my Chat#Terminal:~$ project, I should have a make.bat file which shows how to statically link libcurl to a program using gcc or mingw. And finally static-compile the whole program, and ship without any runtime dependency!
On a side-note, curl's precompiled-binary website says: Curl_x.x.x is statically linked with: [list of libraries you provided]. Break your misconception that, the statement made at the website means: Curl.exe is statically linked with the libs, not libcurl.
I'm trying to compile a simple SFML program test in static mode, i defined SFML_STATIC before any sfml header inclusion, i use "-s-d" prefixed libs for it.
I added the extlibs using this order:
mingw32
user32
gdi32
winmm
dxguid
libfreetype.a
libglew.a
libjpeg.a
libopenal.a
libsndfile.a
I finally got a lot of undefined reference to glfunctions and GLEW_ARB_texture... to FT_Fond_Face, etc.
(Note: When i use dynamic linking which needs Dll files, no reference problem occurs, i use Windows 7, sfml-gcc-4.7.1-tdm-32bit, and codeBlocks 13.12)
The correct linking order of sfml extlibs are given here for each of sfml module http://www.sfml-dev.org/faq.php#tr-cb-linker :)
I am trying to compile an example c application that is using pkcs#11 to finds all
the private keys on the token, and print their label and id, but getting following errors
/tmp/ccAqQ7UI.o: In function initialize':
pkcs11_example1.c:(.text+0x8e5): undefined reference to C_Initialize'
/tmp/ccAqQ7UI.o: In function `get_slot':
The example is taken from here
compilling by using following command;
`gcc pkcs11_example1.c -o slots -L /usr/lib/opensc-pkcs11.so`
I am not sure which library i should link after -L.
Can anyone guide how to compile this and are there some libraries required to link.
C_Initialize and other 60+ functions with "C_" prefix are cryptoki functions defined in PKCS#11 specification. They are usually implemented in standalone library provided by HSM vendor. Looking at your code samples I would say that you need to directly link also PKCS#11 library or you can modify the code to dynamically load PKCS#11 library in runtime with LoadLibrary or dlopen and then acquire pointers to all cryptoki functions via the C_GetFunctionList call. You can also take a look at pkcs11-logger the source code for an example on how to do that.
The link command you give, gcc pkcs11_example1.c -o slots -L /usr/lib/opensc-pkcs11.so, is wrong.
-L takes just path, which is added to paths where libs are searched from, but /usr/lib is default so you don't need this switch at all.
You are missing -l, which takes the library name without lib prefix or .so suffix, so looks like you need -lopensc-pkcs11.
So, first make sure your library file really is /usr/lib/libopensc-pkcs11.so (note lib prefix!) possibly with verion numbers following. Then change build options so link command becomes
gcc pkcs11_example1.c -o slots -lopensc-pkcs11
I'm trying to link against a shared library (apr) on AIX 5.3 using gcc/libtool.
The output from the compiler is as follows (with some irrelevant flags removed for the sake of simplicity):
libtool: link: gcc -o test test.o -L/opt/freeware/lib -lapr-1 -lpthread -Wl,-blibpath:/opt/freeware lib:/usr/lib:/lib
Then I checked what shared libs the resulting binary uses:
$ ldd test
test needs:
/usr/lib/libc.a(shr.o)
/usr/lib/libpthread.a(shr_xpg5.o)
/unix
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libpthreads.a(shr_comm.o)
Notice that 'libapr-1' is missing here, though the symbols are there in the binary (verified with nm), which suggests that it is linked in statically.
This wouldn't be such a big problem for simple programs. Unfortunately my code in question uses dynamically loadable modules. The main program calls apr_initialize which sets a static variable 'apr_pools_initialized' inside the library. The loadable modules then try to use apr_pool_create which first check whether the initialization has been performed. Since they have their own statically linked apr, the static variable 'apr_pools_initialized' is not at the same memory location what the main program initialized. This makes the statically linked binary non-functional.
The apr library is installed using a precompiled binary rpm (apr and apr-devel). The relevant library files are there:
# rpm -ql apr|grep \\.so$
/opt/freeware/lib/libapr-1.so
/opt/freeware/lib64/libapr-1.so
/usr/lib/libapr-1.so
# rpm -ql apr-devel|grep \\.a$
/opt/freeware/lib/libapr-1.a
/opt/freeware/lib64/libapr-1.a
/usr/lib/libapr-1.a
/usr/lib64/libapr-1.a
/usr/lib64/libapr-1.so
I tried to remove the '.a' files hoping that the linker would have no choice but to use the '.so' and link it dynamically, unfortunately AIX is different and this does not work.
Regarding this topic I have found this answer and another libtool question which give some insight.
The question is: How can I link this to my binary dynamically?
Actually the links referenced contained the solution to this problem, which is:
-Wl,-brtl
Adding these LDFLAGS solved the linking problem.
Same source, all that, just want a static and shared version both. Easy to do?
Yes, it's moderately easy. Just use two "add_library" commands:
add_library(MyLib SHARED source1.c source2.c)
add_library(MyLibStatic STATIC source1.c source2.c)
Even if you have many source files, you can place the list of sources in a Cmake variable, so it's still easy to do.
On Windows you should probably give each library a different name, since there is a ".lib" file for both shared and static. But on Linux and Mac you can even give both libraries the same name (e.g. libMyLib.a and libMyLib.so):
set_target_properties(MyLibStatic PROPERTIES OUTPUT_NAME MyLib)
But I don't recommend giving both the static and dynamic versions of the library the same name. I prefer to use different names because that makes it easier to choose static vs. dynamic linkage on the compile line for tools that link to the library. Usually I choose names like libMyLib.so (shared) and libMyLib_static.a (static). (Those would be the names on linux.)
Since CMake version 2.8.8, you can use "object libraries" to avoid the duplicated compilation of the object files. Using Christopher Bruns' example of a library with two source files:
# list of source files
set(libsrc source1.c source2.c)
# this is the "object library" target: compiles the sources only once
add_library(objlib OBJECT ${libsrc})
# shared libraries need PIC
set_property(TARGET objlib PROPERTY POSITION_INDEPENDENT_CODE 1)
# shared and static libraries built from the same object files
add_library(MyLib_shared SHARED $<TARGET_OBJECTS:objlib>)
add_library(MyLib_static STATIC $<TARGET_OBJECTS:objlib>)
From the CMake docs:
An object library compiles source files but does not archive or link
their object files into a library. Instead other targets created by
add_library() or add_executable() may reference the objects using an
expression of the form $<TARGET_OBJECTS:objlib> as a source, where
objlib is the object library name.
Simply put, the add_library(objlib OBJECT ${libsrc}) command instructs CMake to compile the source files to *.o object files. This collection of *.o files is then referred to as $<TARGET_OBJECT:objlib> in the two add_library(...) commands that invoke the appropriate library creation commands that build the shared and static libraries from the same set of object files. If you have lots of source files, then compiling the *.o files can take quite long; with object libraries you compile them only once.
The price you pay is that the object files must be built as position-independent code because shared libraries need this (static libs don't care). Note that position-independent code may be less efficient, so if you aim for maximal performance then you'd go for static libraries. Furthermore, it is easier to distribute statically linked executables.
There is generally no need to duplicate ADD_LIBRARY calls for your purpose. Just make use of
$> man cmake | grep -A6 '^ *BUILD_SHARED_LIBS$'
BUILD_SHARED_LIBS
Global flag to cause add_library to create shared libraries if on.
If present and true, this will cause all libraries to be built shared unless the library was
explicitly added as a static library. This variable is often added to projects as an OPTION
so that each user of a project can decide if they want to build the project using shared or
static libraries.
while building, first (in one out-of-source directory) with -DBUILD_SHARED_LIBS:BOOL=ON, and with OFF in the other.
Please be aware that previous answers won't work with MSVC:
add_library(test SHARED ${SOURCES})
add_library(testStatic STATIC ${SOURCES})
set_target_properties(testStatic PROPERTIES OUTPUT_NAME test)
CMake will create test.dll together with test.lib and test.exp for shared target. Than it will create test.lib in the same directory for static target and replace previous one. If you will try to link some executable with shared target it will fail with error like:
error LNK2001: unresolved external symbol __impl_*.`.
Please use ARCHIVE_OUTPUT_DIRECTORY and use some unique output directory for static target:
add_library(test SHARED ${SOURCES})
add_library(testStatic STATIC ${SOURCES})
set_target_properties(
testStatic PROPERTIES
OUTPUT_NAME test
ARCHIVE_OUTPUT_DIRECTORY testStatic
)
test.lib will be created in testStatic directory and won't override test.lib from test target. It works perfect with MSVC.
It's possible to pack eveything in the same compilation breath, as suggested in the previous answers, but I would advise against it, because in the end it's a hack that works only for simple projects. For example, you may need at some point different flags for different versions of the library (esp. on Windows where flags are typically used to switch between exporting symbols or not). Or as mentionned above, you may want to put .lib files into different directories depending on whether they correspond to static or shared libraries. Each of those hurdles will require a new hack.
It may be obvious, but one alternative that has not been mentionned previously is to make the type of the library a parameter:
set( ${PROJECT_NAME}_LIBTYPE CACHE STRING "library type" )
set_property( CACHE ${PROJECT_NAME}_LIBTYPE PROPERTY STRINGS "SHARED;STATIC" )
add_library( ${PROJECT_NAME} ${PROJECT_NAME}_LIBTYPE ${SOURCE_FILES} )
Having shared and static versions of the library in two different binary trees makes it easier to handle different compilation options. I don't see any serious drawback in keeping compilation trees distinct, especially if your compilations are automated.
Note that even if you intend to mutualize compilations using an intermediate OBJECT library (with the caveats mentionned above, so you need a compelling reason to do so), you could still have end libraries put in two different projects.