Have Already read dozens of post on the subject but nothing seems to match my problem.
So, I've upgraded my VS2013 'VS2015'.
I have dozens of projects in my solution using boost as additional library.
I've also recompile boost.
when compiling my projects I get this error.
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc120-mt-s-1_55.lib'
lib libboost_thread-vc120-mt-s-1_55.lib used to exists when I compiled boost for VS2013. But after compiling boost for VS2015 the lib name has changed to
libboost_thread-vc140-mt-s-1_55.lib (which is great).
Question
Why does the linker looking for file libboost_thread-vc120-mt-s-1_55.lib. How does it knows which file to link?
I had the exact same problem converting from VS2013 to VS2015, and at the same time changing Boost version from 1.59 to 1.61.
After two days of googling, SO'ing and trying out different variants, I seem to have ended up with a working solution, although I don't know why.
I compiled Boost (I believe exactly like the four previous attempts) using VS2015 x86 Native Tools Command Prompt with:
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
> .\bootstrap
> .\b2 install --prefix="<MY_BOOST_DIR>\msvc14" --buildtype=complete --build-dir="<MY_BOOST_DIR>\build" toolset=msvc-14.0 variant=release,debug link=shared -j4 --address-model=32
After this I tried compiling my very simple test
#include <boost\filesystem.hpp>
#include <iostream>
int main()
{
boost::filesystem::path rootpath = boost::filesystem::current_path();
std::cout << rootpath.string() << std::endl;
std::cin.ignore();
return 0;
}
With the appropriate Boost directories set for include and lib dirs. While the file 'libboost_filesystem-vc140-mt-gd-1_61.lib' verifiably is at the lib folder, VS2015 still complained it couldn't find the file.
As a last random poke at it, I changed my target platform to x64, after which the linker error changed to a warning about the conflict:
warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64' ...so for some reason, now VS was able to find the file! After which changing the target back to X86 resulted in a working configuration, while nothing really changed.
Could somebody explain/verify this? Does this solve your case, #idanshmu?
Related
My project is using some libs of libavcodec on Visual Studio 2010.
After updating the libs (replacing the lib and includes from Libav) and resolving all Compiler Errors (after 3 years a few things changed in libavcodec), the project compiles without a problem, but my compiled dll does not work.
I am 99% sure it is some dependency problem. Sure i did not only update the linked libs of my project but also placed the correct new dlls into the build folder.
The strange thing i have never seen is that dependency walker detects totally wrong imports from the different dlls, see image.
As you can see, all linked libs seem to indicate the same imports - functions that those libs just don't export.
The only thing i do in that direction besides specifying the libs in the linker section is including the .h files in my program and then of course use them heavily;-)
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavutil/opt.h>
#include <libavutil/imgutils.h>
#include <libavformat/avformat.h>
#include <libswscale/swscale.h>
#include <libswresample\swresample.h>
}
What i tried:
Make sure the correct libs and headers are used by the project
clean the build path, tried debug und release build
checked if there are new includes that i may have forgotten to link (this would have ended up in a compiler errror anyways)
restart VStudio
built a test program that links to the same dlls, there the correct imports are shown automatically
compiled with VS 2013, no change at all
Custom building binaries depending upon your current project settings is key to avoiding annoying linker errors like the one your are facing.
You can use vcpkg.exe from github to build the ffmpeg project and rebuild binaries for x86 or x64 machine.
After installing vcpkg on your system, goto to the Powershell prompt and enter .\vcpkg install ffmpeg. After completion of installation enter ".\vcpkg integrate install" so that your latest ffmpeg libraries are available for use.
I have a CMake file which does this:
find_package(Boost COMPONENTS system filesystem)
add_library(MyModule MODULE main.cpp)
target_include_directories(MyModule PUBLIC ${Boost_INCLUDE_DIRS})
target_link_libraries(MyModule Boost::system Boost::filesystem)
I'm using VS 2017 as my generator. When I generate the project file with cmake, it finds boost_system-vc141-mt-1_63.lib and I can see that it is in the linking rules of the vcxproj. However, when I try to compile I get this error:
LINK : fatal error LNK1104: cannot open file 'libboost_system-vc140-mt-1_63.lib
Note the different generators (vc140 vs vc141). I know my compiler has output the right values because I built boost from source, so I tried to just rename vc141 to vc140, but the error stayed the same. I also confirmed that vc140 is not referenced in the project file.
What's going on? How can I force boost to link to the correct version?
When building with Visual Studio, boost has some pragma statements which do the linking for you. This is called "Auto-linking" and it over-rides any command-line arguments you may be passing to the linker.
The solution is to define BOOST_ALL_NO_LIB. This can be done in two ways:
In source code before including boost headers as #define BOOST_ALL_NO_LIB.
It could be added to your cmake file as: add_definitions("-DBOOST_ALL_NO_LIB").
As of CMake 3.5: Use the disable_autolinking imported target:
target_link_libraries(MyModule Boost::system Boost::filesystem Boost::disable_autolinking)
I installed VS2015 and QtCreator 3.5 and compiled Qt5.5 from source as a binary distribution is not available for the visual c++ compiler shipped with VS2015.
I tried to compile my project which was developed using the visual c++ compilers from VS2012/VS2013 and QtCreator 3.3x with Qt 5.2 and Qbs - on a different machine - from QtCreator and with my new setup neither QtCreator nor Qbs from command line are able to link the application.
I narrowed the problem down using the Qbs helloworld example
import qbs
CppApplication {
type: "application" // To suppress bundle generation on Mac
consoleApplication: true
files: "main.cpp"
Depends {
name: "Qt"
submodules: [
"core"
]
}
}
Which gives the following output when building with qbs from the command line
compiling main.cpp
linking halloqbswelt.exe
ERROR: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe /nologo /DEBUG /PDB:halloqbswelt.pdb /OSVERSION:5.02 /SUBSYSTEM:CONSOLE,5.02 /MANIFEST /MANIFESTFILE:D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\intermediate.halloqbswelt.exe.manifest D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\.obj\3a52ce780950d4d9\main.cpp.obj .lib /OUT:D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\intermediate.halloqbswelt.exe /LIBPATH:D:\projekte\3rd_party\qt\qtbase\lib
LINK : fatal error LNK1104: cannot open file '.lib'
ERROR: Process failed with exit code 1104.
The following products could not be built for configuration Qt5-debug:
halloqbswelt
Rather cryptic so I'll highlight the problem from the above output
[...] .obj\3a52ce780950d4d9\main.cpp.obj .lib /OUT: [...]
So the empty .lib file is the problem.
Comparing the linker statement with that from the other machine, the empty .lib is at the same position where Qt5Core.lib should be.
Thus tried to investigate why Qbs does not resolve the paths proberly; I looked at the core.qbs module but couldn't find anything different from the file on the machine with the working setup.
Finally I decided to recompile the Qt library and setup the Qbs/QtCreator profiles from scratch. Done and it worked, until I restarted QtCreator, now neither (Qbs from command line, nor QtCreator with its own profile) works anymore.
Has somebody experienced such a behavior?
As said in the comment, http://article.gmane.org/gmane.comp.lib.qt.qbs/682 gave me the right starting point.
Qbs relies on pri/prl files of each submodule from which the dependencies are built (as far as I understood). These pri files are overwritten or some other bad stuff happens when installing Qt built from source in a non-prefix environment (which is the default under Windows) (https://bugreports.qt.io/browse/QTBUG-42959).
So building Qt with a prefix and installing the sources is solves the problem, at least for me.
I'm trying to compile an OpenGL program using Visual Studio 2013, but I get the following error:
Error 1 error LNK1104: cannot open file
'freeglutd.lib' ...
For reference, I have FreeGLUT installed and have configured VS to search the correct directories for the include files and library files. Indeed, VS recognises the GLUT include files just fine. I've also added opengl32.lib and freeglut.lib to the Additional Dependencies.
Why is VS looking for 'freeglutd.lib'? It's definitely not listed in the Additional Dependencies. I can solve the compilation error by renaming 'libglut.lib' to 'libglutd.lib' and removing the former from the dependencies, but I'm just curious why it's behaving this way.
Speaking of Additional Dependencies, is adding opengl32.lib actually necessary? I can compile my (very basic) program without it, but more than one person has said it's required, perhaps for older versions of Visual Studio?
if you check the freeglut_std.h (freeglut V3.0):
/* Link with Win32 shared freeglut lib */
# if FREEGLUT_LIB_PRAGMAS
# ifdef NDEBUG
# pragma comment (lib, "freeglut.lib")
# else
# pragma comment (lib, "freeglutd.lib")
# endif
# endif
so if you don't define NDEBUG, the linker will link to "freeglutd.lib",
you can solve that by defining a NDEBUG in "PreprocessorDefinitions".
Good luck!
Hey man I don't know if you're still having this error but here is a solution. Pretty much the "freeglutd.lib" has to do with debugging, hence the "d" on the end, so what I did was go into the:
Properties > C/C++ > Preprocessor > Preprocessor Definitions and type NDEBUG. Then OK and Apply.
What this does is in the "freeglut_std.h" there is a ifdef for NDEBUG that if it is defined then use "freeglut.lib" otherwise it's going to use the "freeglutd.lib". So by defining it in the Preprocessor Definitions, you are now using the "freeglut.lib". Hopefully this helps you out!
Possibly already answered: freeglut error LNK1104
Also two things to check for:
Are you building in debug or release mode? The d at the end of freeglutd.lib suggests that it's a library meant for debug builds
Try creating a new project from scratch, put some basic runnable code in it that uses freeGLUT and see if VS is linking properly. This will also verify if for some reason the project file of the previous project was corrupted (as #RobertHarvey suggested) or the problem is somewhere else
I solved this problem by compiling freeglut and freeglut_static from generated CMake soluton in Debug mode - freeglutd was created in the lib/Debug directory. You can put this directory into lib path then and it will work!
I have included the boost library in a Codeblocks c++ project.
Now, in the file
boost/function.hpp
there is an include statement
#include <boost/preprocessor/iterate.hpp>
However I get this error in Codeblocks when I try and compile:
/home/arvind/Documents/Workspace/Browser/boost/function.hpp|15|fatal error:
boost/preprocessor/iterate.hpp: No such file or directory|
What am I doing wrong here? I have simply included the Boost library as it is.
Also, I cannot find the screen/option to set the main class (which will actually execute).
How do I do this?(I am new to CodeBlocks hence this question).
Your boost includes seem to be in a non-standard/system directory : /home/arvind/Documents/Workspace/Browser, you must tell the compiler to look there (gcc -I command-line switch).
Go to Project->Build Options->Search Directories->Compiler and add the directory where boost includes are. I don't have a codeblocks install right here so this was from here.
If you can, I would recommand installing boost on your system once and for all instead of just copying files in your codeblocks workspace.