I read a lot of post but I don't yet well understood how to link my target to a static version of a library.
My project depends on poco libraries and, while in linux they are stored in /usr/local/lib (both the static and shared versions) in my windows machine are in d:\libs\poco\lib and d:\libs\poco\bin (where I have an enviroment variable called POCO_DIR = D:\libs\poco)
So, how can I have to write the find_library() directive in cmake file?
Thanks in advance.
You never link with a Poco DLL on windows, not even when you use shared Poco libraries. Linking is always with entries in the %POCO_BASE%/lib. For shared builds, .lib is just a stub ("import library") that takes care of loading the DLL at runtime. See Linking Implicitly for details on how this works.
Poco static libraries can be distinguished from the import libraries for DLLs by the file name - static libs have "mt" ("mtd" for debug binaries, "md" and "mdd" when runtime library DLLs are used) appended to the name. So the import library for PocoFoundation.dll will be named PocoFoundation.lib, while the static library using static runtimes is named PocoFoundationmt.lib. Static library using dynamic runtimes is PocoFoundationmd.lib. See Use Run-Time Library for details.
As for CMake, I am not an expert, but for e.g. static Foundation and Net libraries should be something like this:
FIND_LIBRARY(Poco_LIBRARIES NAMES PocoFoundationmt PocoNetmt PATH_SUFFIXES ${POCO_DIR}/lib)
EDIT: If you define POCO_STATIC in your project, static linking will be automatic through library headers, see e.g. Foundation.h.
Related
Just now I noted that the MinGW Toolchain that comes with the default Qt installation, at least Qt 5.14, comes with a lib directory with libQt5*.a files. Are those files static libraries?
I think so because:
They have a size similar to the ones that I get when I compile Qt statically for release.
$file ./libQt5Core.a outputs ./libQt5Core.a: current ar archive, which is the same that it outputs for the statically compiled ones.
If indeed they're static libraries, how can I tell QMake (for example editing the .pro file) to link to those instead of linking to the shared ones?
Are those files static libraries?
No. They are not static. Qt’s default online installer provides only shared libraries. That *.a files are so-called import libraries.
Import library is an .a or .lib library, but it only contains bit of information needed to tell the linker/OS how your program interacts with the dll’s.
If you need Qt static windows build for some reasons, you have some options:
HARD Build whole Qt (or needed modules) by yourself.
EASY Use vcpkg: vcpkg install qt5:x64-windows-static
With vcpkg you can create custom MinGW triplet if you need MinGW for some reason. But I suggest you stick with MSVC.
I have some problems with linking my macOS app against C libraries.
I have several question related to this issue.
It is better to link app against dynamic or static libraries taking into account that this will be very custom libraries rather not shared with other apps?
I have linked my macOS Xcode app against ~14 static libraries .a and it works fine. I have reconfigured CMakeLists.txt making this libraries and now Xcode project doesn't work. The main change was changing the directory I have
"$(SRCROOT)/../../c/<project_name>/outputs/lib/apple/static"
But now I have both static (.a) and dynamic (.dylib) libraries in the same path
"$(SRCROOT)/../../c/server/outputs/lib/apple"
I don't know whether this should matter, but linking against static libraries causes that after running my Xcode project it complains that it cannot load lib.dylib So maybe it finds this dynamic library under Library Search Paths and tires to load them but don't find them linked?
So I tired to link Xcode macOS app against .dylib libraries and instead of static .a libraries added them in Link Binary with Libraries. The problem is that the error not finding library now also occurs.
Maybe I should change something here ? But what If I will distribute my app to some other computers that will not have libraries in this specific location. How can I include dynamic libraries in Xcode bundle in order to be always findable.
I know I added maybe to many question. But would like to know how to the best solve this issue? Better to link statically or dynamically and then how to correctly achieve this avoiding this error.
UPDATE
It seems that when linking against .dylib it only works when I add path to this library directory to Runpath Search Paths.
It also seems that when I link against static library .a it works when .dylib isn't in the same directory (I moved .a library into /static subdirectory) and then for this moved library error isn't showing any more. But isn't there way to link statically when there is .a and .dylib libraries inside the same directory?
I know this is an old question but it's one of the top results when searching google for "Xcode static linking."
I recently encountered this issue when integrating with Intel IPP, which puts static and dynamic libs in the same directory.
If I used the standard Xcode linking method of adding the library via the "Build Phases | Link Binary with Libraries," Xcode translated that UI into a command line that looked like this:
clang++ ... -L/my/path -lstatic1 -lstatic2 ...
But that causes the linker to prefer the DLL instead of the static library in the same directory.
I worked around this by removing the entries from the "Build Phases | Link Binary with Libraries" window, and adding full relative paths to the libraries in the "Build Settings | Other linker flags" entry:
../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic2.a
This caused Xcode to translate the UI into a command line that looked like this:
clang++ ... ../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic1.a ...
Which linked the libraries statically.
Finally, I have linked this Xcode macOS project with multiple dynamic C libraries (.dylib).
REMARK
In order to link with static libraries (.a) They cannot be placed side by side with dynamic libraries! path/project_name/outputs/lib/apple/*.dylib and then place static libs under path: path/project_name/outputs/lib/apple/static/.a As XCode tries to link dynamic libraries if they found them on Libraries Search Path in Build Settings.
DYNAMIC C LIBRARIES LINKIN IN XCODE
Add dynamic libraries to Build Phases tab and Link Binaries with Libraries section as on the image
Embed all this dynamic libraries in output macOS Application Wrapper
You get something like this:
Then in Build setting add Libraries Search Paths
And finally add Runtime Search Paths in Build Settings
I have a static library that links to a statically built Boost library.
However, when my executable is linking to my own static library, it will fail with a message saying that it cannot find the Boost library.
I thought when my static library is statically linked to the Boost library, any further upstream dependency of the Boost library should be gone. Isn't this correct?
MyLib.lib -> linked to static Boost library
MyApp.exe -> links to MyLib.lib statically, Failed!, cannot find Boost library
Any help is appreciated.
Static libraries are really nothing more than a collection of object files. If you want to use a static library that depends on other libraries, you need to link withe other libraries as well.
I want to build a shared library that uses ZipArchive using GNU Autotools but I'm having this problem:
Warning: linker path does not have real file for library -lziparch.
I have the capability to make that library automatically link in when
you link to this library. But I can only do this if you have a
shared version of the library, which you do not appear to have
because I did check the linker path looking for a file starting
with libziparch and none of the candidates passed a file format test
using a file magic. Last file checked: /usr/local/ZipArchive/ZipArchive/libziparch.a
The inter-library dependencies that have been dropped here will be
automatically added whenever a program is linked with this library
or is declared to -dlopen it.
If I build a static library or if I use a shared library of ZipArchive it works but the problem is that the makefile that comes with ZipArchive source code only builds a static library.
How can I force Libtool to link with a static library?
Generally, static archives are created with non-pic object files and they cannot be put into shared libraries.
What this message is telling you though, is that when a program links to YOUR library using Libtool, that -lziparch will get added to the link. So you don't need to change anything unless you're building a module for an interpreted language. In that case, you will have to build ZipArchive as a shared library. In addition, this wouldn't work on a platform like MS Windows where shared libraries (DLLs) have to resolve all their symbols at link time.
All that said, if your ziparch static lib is PIC code, you can use the -whole-archive flag when linking it to your library. This would be the least portable solution though.
In my C++ application I have a static library (libCOMMON.a) that links to boost libraries: system, filsystem, timer and chrono.
I am using CMake and here is how I create and link libCOMMON.a:
ADD_LIBRARY(COMMON ${COMMON_SRCS})
target_link_libraries(COMMON
${BOOST_LIB_DIR}/libboost_filesystem.a
${BOOST_LIB_DIR}/libboost_system.a
${BOOST_LIB_DIR}/libboost_timer.a
${BOOST_LIB_DIR}/libboost_chrono.a
)
I also have plugins for this application that links to libCOMMON.a. The plugins are built as dynamic libraries. Everything compiles ok (using gcc) but when I start the application, the plugins can't be loaded because some symbols in the dynamic libraries related to boost cannot be resolved.
The solution was to link each of the plugins to boost. Is there a better way ?
I thought that if boost libraries are linked statically into libCOMMON.a, it would be enough to link the plugins to libCOMMON.a.
Can someone explain what's happening ?
Thanks
I think the problem is that boost libraries are built as dynamic libraries by default. Even if the ".a" suggests that they are built as static libraries, the lib folder of boost contains a ".so" library with each ".a". Which means that libCOMMON.a is linked dynamically to boost libraries. For this reason, the plugins that statically links to libCOMMON.a has also to dynamically link to boost libraries. A better solution would be to build boost libraries as static libraries.