In my current project I'm using the library libcurl, previously installed by powershell. I'm including it using #include "curl/curl.h" and compiling works but I have a linking error that says:
:LNK1104:cannot open file curl/libcurl_a_debug.lib
I dont have this file. In my current directory i found only libcurl.lib. I already added the path to the directory in Additional library directories and Additional include directories. I'd like to know is any other way to solve this error.
In release mode i have an error that linker cannot open file libcurl_a.lib. On the other hand in debug folder i have a libcurl-d.lib file.
According to Microsoft Docs, there are several common causes for this issue:
The path to your library file may be incorrect, or not wrapped in
double-quotes. Or, you may not have specified it to the linker.
You may have installed a 32-bit version of the library but you're
building for 64 bits, or the other way around.
The library may have dependencies on other libraries that aren't
installed.
By the way, could you add libcurl.lib in Properties->Linker->Additional Dependencies? If not, you could add it.
You could try to use compiled statements instead of settings.
#ifdef _DEBUG
#pragma comment(lib,"..\\debug\\lib name")
#else
#pragma comment(lib,"..\\release\\lib name")
#endif
Also, I read the official documentation of curl. There is a description of Windows link errors:
5.7 Link errors when building libcurl on Windows!
You need to make sure that your project, and all the libraries (both static and dynamic) that it links against, are compiled/linked against the same run time library.
This is determined by the /MD, /ML, /MT (and their corresponding /M?d) options to the command line compiler. /MD (linking against MSVCRT dll) seems to be the most commonly used option.
When building an application that uses the static libcurl library, you must add -DCURL_STATICLIB to your CFLAGS. Otherwise the linker will look for dynamic import symbols. If you're using Visual Studio, you need to instead add CURL_STATICLIB in the "Preprocessor Definitions" section.
If you get linker error like "unknown symbol __imp__curl_easy_init ..." you have linked against the wrong (static) library. If you want to use the libcurl.dll and import lib, you don't need any extra CFLAGS, but use one of the import libraries below. These are the libraries produced by the various lib/Makefile.* files:
Target: static lib. import lib for libcurl*.dll.
-----------------------------------------------------------
MingW: libcurl.a libcurldll.a
MSVC (release): libcurl.lib libcurl_imp.lib
MSVC (debug): libcurld.lib libcurld_imp.lib
Borland: libcurl.lib libcurl_imp.lib
I suggest that you could try the method.
Related
I have a dependency like this in a large project:
MyEXE --> MyDLL --> MyStaticLib
Which means that my executable (MyEXE) is dependent on a dll (MyDLL) and the dll uses an static lib (MyStaticLib). The problem is that I can call the MyStaticLib methods from MyEXE and it compiles and links without any issues. I checked the Linker/Input page on Visual Studio (2015) of MyEXE project, but I cannot find MyStaticLib as one of the dependencies of MyEXE.
Now the questions are:
How it is possible for MyEXEto call MyStaticLib methods without any explicit dependancies?
Is there any tools on Windows to list all of the static libs used by an executable? (here is a solution for Linux)
Update 1: There is no #pragma comment(lib, ...) directive in the headers of the MyStaticLib. So, the static lib cannot be linked to the .exe using this directive.
MSVC at least has a mechanism for implicit dependencies, done through the #pragma comment(lib, ...) directive. Check the headers for the static library and make sure that there is no such.
Also, if using a static library provided through 'vcpkg' and you have done "vcpkg integrate install" an MSBuild file is added to the project build system that automatically imports everything that vcpkg generates.
Also, link.exe has a /VERBOSE:LIB option that will print out the libraries that are searched, though it won't tell you why that particular library was added to the build.
I'm having an issue compiling a static library using Code::Blocks 13.12. I need to use a third party static library from within my own static library. So, I have libOtherLib.a and I'm trying to build libMyLib.a and link in libOtherLib.a. The problem is that the linker is not including libOtherLib.a during the linking phase of the build. Here is some additional information:
I am using the GNU GCC Compiler
In Project build options for the whole project (not specifically Debug or Release)
I have added libOtherLib.a in the Link Libraries list in the Linker Settings
I have added the path to libOtherLib.a in the Search directories -> Linker list
I have added the path to the .h file for libOtherLib.a in the Search directories -> Compiler list
The library compiles completely fine (produces bin/Debug/libMyLib.a with no errors)
Any help would be greatly appreciated. I have an inkling that it is related to this being a Static Library rather than an application (console or otherwise), but I'm not sure how or why. I did change the build target Type to "Console Application" in the Project Properties window and it looked like it was linking in libOtherLib.a, but it had other errors because this code is meant to be a library rather than an application.
Here is the linker command that is executed at the end of the build. libOtherLib.a is not there anywhere, that is the problem, just not sure what the solution is.
ar -r -s bin/Debug/libMyLib.a <all of my .o files>
Possible causes of the problem would also be nice - if this is mostly like the compiler, the linker, the setup or Code::Blocks itself.
When building a static library you are just putting together a bunch of object files into an entity easier to ship and use. There is no linking done when building a static library.
The unresolved references from your library are dealt with when building an application or certain shared objects. You'd just ship your library and require that users also supply the library your library deoends on when building.
If you want to include the library you are depending on in your library you can extract the object files from tgat library and include them into your library. Although technically possible it is questionable if you have the rights to do so. Also, that is normally not the way things are done and I'd recommend against doing so.
You can't link a static library in anoter static library.
However,you can do this:
Suppose MyPrograme.exe need to link static library libMyLib.a,make MyPrograme.exe also link libOtherLib.a.
Since libMyLib.a is static library,there is no need to link libMyLib.a.Just inclue the headers.
When build a static library,it will only be compiled,not be linked.
Despite all this "linking is not the right term for this" philosophy, you can patch Code::Blocks compiler configuration to support this, for example for the GCC/G++ compiler.
http://green-candy.osdn.jp/codeblocks_config.html
The idea is that you replace the "Link object files to static library" script in the "Advanced compiler options" window of GCC with:
rm -f $static_output
$lib_linker -r -s -T $static_output $link_objects
$lib_linker -r -c -T $static_output $link_options
Then you can put the relative path to your "libOtherLib.a" in the "Other linker options" editbox of your projects. This mod is not really officially endorsed but it works in my projects, so you get static libs in static libs just like in MS Visual Studio!
Turns out static linking was working, but only for Qt libraries. My 3rd party library QtSerialPort is not linking statically. After some reasearch, I've found that I either have to build this library statically or I have to link directly to a .pri file in my .pro file.
I'm not sure how to do either since it seems QtSerialPort has not been designed for static linking.
The .pri method I really don't understand and has been vaguely described in these two links:
http://qt-project.org/forums/viewthread/15223
http://www.qtcentre.org/archive/index.php/t-54505.html
Does anyone have any adivce on how to get either of these methods to work? Or possibly another method?
Also, MSVCP100.dll is not linking statically if anyone could give me any advice on that.
==================================================================================
I am trying to get Qt to statically link libraries so that I can make a standalone application. I have followed various tutorials on how to build Qt statically then building a static application but I am not having much luck. I believe I have succesfully built Qt with static linking because the application has grown in size from 79KB to 7+MB but I am still getting errors saying QtCore4.dll and QtSerialPort.dll are missing. Also, another issue I'm having when using this static configuration, which isn't too serious, is that when I close my program Windows thinks it has crashed and gives me a window saying MyProgram.exe has stopped working...
I am on a Windows machine using MSVC 2010 with Qt 4.8.5 and am using the third party library QtSerialPort.
What I've done accoring to the guides I've been reading is:
Download and extract qt-everywhere-opensource-src-4.8.5.zip
Open /mkspec/mwin32-msvc2010/qmake.conf and change the follwing lines to
CONFIG += qt warn_on release incremental flat link_prl precompile_header autogen_precompile_source copy_dir_files debug_and_release debug_and_release_target
and
QMAKE_CLFAGS_RELEASE = -O2 -MT
I then open the MSVC2010 command prompt and cd to this . I then enter the commands
configure -static -release -platform win32-msvc2010
nmake sub-src
After this is done I open my project and add
CONFIG += static
to the .pro file. In QtCreator I then go into Projects, Manage Kits then to Qt Versions and browse to the qMake I just generated. I add a new Kit with this version of qMake. I then clean all and switch to this new kit and run qmake from QtCreator. I then use msvc2010 command prompt to go to the directory where the files are generated and then
nmake release
This generates a rather large .exe but like I said, it's still depending on a couple .dll's.
For static linking of external library one have a couple options, both have their pros and cons.
I. Compile the library for static linking yourself. Link to it.
Look for possible existing configuration switches for static linking. There can be something like QTSERIALPORT_STATIC = no, etc. in the library's .pro/.pri files. Just say yes for the library to compile for static linking and go to the step 4!
In .pro/.pri file replace CONFIG += dll with CONFIG += static.
Remove export declarations from the library. Typically Qt library symbols are declared with some definition like QTSERIALPORT_EXPORT which expands to Q_DECL_EXPORT/Q_DECL_IMPORT in shared library build / its header files usage when linking. You'll need to find where this QTSERIALPORT_EXPORT is defined and replace it with empty definition:
#define QTSERIALPORT_EXPORT // in source file
or
DEFINES += QTSERIALPORT_EXPORT # in .pro/.pri file
Build the library.
Link to the library .lib/.a file, use the library header files for symbol declarations in your project.
II. Include the library source files into your project and compile them within it (no linking at all).
Include all the source files of the library into your project (add to SOURCES in qmake project file)
Determine all the stuff the library depends on (other libraries, Qt options, etc.) and include it also into your .pro file.
OR
Include the proper .pri file into your .pro if the library author provides it for in-project compilation (i.e. include(QtSerialPort.pri) or something.)
Remove export/import declarations from the library source code — as described in the item 3 of part I.
Build your project.
I'm trying to test out some code which makes use of boost::filesystem for various things.
I built the static version of boost 1.51 for vc11, and the intended libraries came out as expected.
Here are the flags I used:
b2 --with-filesystem --build-type=complete --build-dir=.\build link=static runtime-link=static
And here's the list of files it generated:
libboost_filesystem-vc110-mt-s-1_51.lib
libboost_filesystem-vc110-mt-sgd-1_51.lib
libboost_filesystem-vc110-s-1_51.lib
libboost_filesystem-vc110-sgd-1_51.lib
libboost_system-vc110-mt-s-1_51.lib
libboost_system-vc110-mt-sgd-1_51.lib
libboost_system-vc110-s-1_51.lib
libboost_system-vc110-sgd-1_51.lib
I then created a new Win32 DLL project and added the proper include/lib directories.
But when I try to compile, I get the following output:
LNK1104: cannot open file 'libboost_filesystem-vc110-mt-gd-1_51.lib
But this file does not exist because (afaik) it IS NOT the static version of the library...
Which is odd because I never asked to link against the DLL version anywhere in my project!
So why is my project complaining about a library which I never asked to use?
Do the boost headers automatically try to link against their corresponding libs?
Is there some sort of preprocessor flag I should be setting to tell boost I want to use the static, single-threaded version of boost::filesystem?
UPDATE:
I have been informed in the comments that boost does in fact try to auto-link for compilers which support it, via <boost/config/auto_link.hpp>...
After several attempts to properly configure these headers to use the static, /MDd (debug) & /MD (release) versions of boost, I am still getting this error.
So if anyone could tell me how to properly configure OR disable this feature, I will mark it as the answer.
Also, am I correct in assuming that libboost_filesystem-vc110-s-1_51.lib and libboost_filesystem-vc110-sgd-1_51.lib are the proper /MD and /MDd libs?
Thanks!
To disable auto-link you need to define BOOST_ALL_NO_LIB. From the boost documentation:
// BOOST_ALL_NO_LIB: Tells the config system not to automatically select
// which libraries to link against.
// Normally if a compiler supports #pragma lib, then the correct library
// build variant will be automatically selected and linked against,
// simply by the act of including one of that library's headers.
// This macro turns that feature off.
But don't do that - it will not solve your problem. Auto-link is usually right, i.e. you are either linking to the wrong libraries or you have incorrectly configured your preprocessor macros. If linker wants to link to the shared libraries I would guess that you defined BOOST_ALL_DYN_LINK or BOOST_FILE_SYSTEM_DYN_LINK and BOOST_SYSTEM_DYN_LINK. Remove it and it should link just fine.
I am developing a Math application which can be extended by writing python scripts.
I am using Qt 4.6.3 (built as static library, debug and release versions) and Boost 1.43.0 (built as static library, runtime-link also set to static, multi-threaded version, debug and release). Everything is built with MSVC++2008. Boost built the following libraries:
libboost_python-vc90-mt-s-1_43.lib
libboost_python-vc90-mt-s.lib
libboost_python-vc90-mt-sgd-1_43.lib
libboost_python-vc90-mt-sgd.lib
My project compiles, but gives the following error during the linking phase:
1>Linking...
1>LINK : fatal error LNK1104: cannot open file 'boost_python-vc90-mt-gd-1_43.lib'
Why is it not selecting one of my compiled libraries?
I think the s in the library names stands for static, but then the auto-linking feature seems to select a dynamic library, and I want it all linked statically in one executable.
The same happens with the regex library: I have the same 4 regex libraries compiled and a quick test shows this linking error:
1>LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc90-mt-gd-1_43.lib'
What to do?
You can define BOOST_ALL_NO_LIB. This prevents automatic linking of boost libraries and you must then link the required boost libs manually.
If 's' stands indeed for static (I don't know all those modifiers by heart), define the BOOST_ALL_DYN_LINK symbol while compiling (add it to the command line options). It tells boost to link to the DLL libraries. Alternatively, compile/install static boost libraries.
The problem is fixed, during the compilation of the boost libraries, I selected the link=static option. Which creates static libraries. I also selected runtime-link=static option, and this was wrong!
The solution for this problem was compiling boost with runtime-link=shared. Now some extra libraries are added, with the correct filenames, so the linker can find them. At first the compiler still searches for the dll library (boost_python-vc90-mt-gd-1_43.lib, instead of libboost_python-vc90-mt-gd-1_43.lib), everything else from boost links automatically to a static library, but because boost.python has a different auto-linkage set up, when you provide BOOST_PYTHON_STATIC_LIB, it finally links to the right library and it works!