After loading an existing MFC application in Visual Studio 2008, I am left with one linking error:
LINK : fatal error LNK1104: cannot open file '..\..\xpressmp\lib\xprm_rt.lib'
I have looked "everywhere", but I can't figure out where the relative path is set. The lib file is located in C:\xpressmp\lib, and I have added this directory both under Tools-Options->Projects and Solutions->VC++Directories->Library files and Project->Properties->Linker->Additional Library Directories. I also searched all files in the project to no avail.
I have the library file (xprm_rt.lib) listed under Additional Dependencies for both Debug and Release. I also tried adding the path there, but that did not help. I cannot find any #pragma comment-directives.
About the LNK1104, the file clearly does not exist in the location that the linker is searching. But I can't see why it is searching there (..\..\...) as I have not specified any relative paths.
Any help appreciated :-)
UPDATE:
In the project .vcproj file, I found the following xml:
<File RelativePath="..\..\XpressMP\lib\xprm_rt.lib"></File>
<File RelativePath="..\..\XpressMP\lib\xprs.lib"></File>
After deleting these lines (where were they set?), I was able to link successfully. Thanks for your help, it seems the relative library path was indeed being appended "automatically" by VS.
Thanks both of you, I think it was Nick that put me on the right track.
In the project properties, look under Configuration Properties -> Linker -> Input -> Additional Dependencies, for each of your project's configurations (Debug, Release, etc). Also, look for #pragma comment(lib, ...) directives in the code.
As you've added the C:\xpressmp\lib folder to the library search path in VC++ Directories, check that only the library file name is specified under Additional Dependencies, and this does not include the path (i.e, xprm_rt.lib, not ..\..\xpressmp\lib\xprm_rt.lib).
Also, have you tried each of the solutions in the LNK1104 error documentation?
It sounds like one of a couple possibilities to me:
The library itself is setting the lib include path via a #pragma comment(lib, ...) directive; search library headers to see if that's the case
You have a project for the library included in your solution which your main project is dependent on, and the relative library path is being appended automatically by VC; check the command line property page for the main project to see if that's the case
That's what I can think of which could cause the error; hope it helps.
Thanks for answering so swiftly!
I have the library file (xprm_rt.lib) listed under Additional Dependencies for both Debug and Release. I also tried adding the path there, but that did not help. I cannot find any #pragma comment-directives.
About the LNK1104, the file clearly does not exist in the location that the linker is searching. But I can't see why it is searching there (..\..\...)
Related
I'm getting the following error :
"fatal error C1083: Cannot open include file"
for one of my header files being #included in stdafx.h. I have set the include and library paths in the project dependencies, Tried to include them in additional include section. On top of that when I right click the
#include <BCGCBProInc.h>
it is able to open the file and show it to me. So it can find and open the file but instead gives me the error. I am using VS2012 on Windows 7 and the header is in a different location then the project.
What am I doing wrong / not doing right?
1.
#include <BCGCBProInc.h>
is not the same as
2.
#include "BCGCBProInc.h"
Different search pathes apply to both variants of including a file.
The pathes looked up when using variant 1. are those defined as default search pathes like
/usr/include for IXish systems
$(VCInstallDir)include also called VC++ Directories for VC
The pathes used when using 2. are those added via the option -I (/I for VC).
In Visual Studio, right-click your project and choose Properties. Select the VC++ Directories option in the left pane, and then look at the Include Directories and Library Directories in the right pane. Make sure they are using relative paths and not absolute paths. If they must be absolute paths, then every machine you run this project on will have to have the exact same path. Absolute paths look like this:
D:/Development/MyProject/includes
Relative paths can be done using $(ProjectDir) to make it relative to the project, or $(SolutionDir) to make it relative to the solution (if different from project), and would look something like this:
$(ProjectDir)../includes
or
$(SolutionDir)includes
What I had to do to get it to compile was change
#include "BCGCBProInc.h"
to this
#include "C:\Program Files (x86)\BCGSoft\BCGControlBar Professional Evaluation\BCGCBPro\BCGCBProInc.h"
I'm not sure why because I included the path in the VC++ Directories. When I browse for the path it changes (x86) to %29x86%29 which is what I thoght was screwing it up but that is not the case because I manually changed it back to (x86).
My plan is when I eventually get what i need to get done, I will bring the libs and includes into the project locally and make the paths relative
I have recently gone from Code::Blocks to Visual Studio, and in Code::Blocks one could just add a class and then include it straight away. However, whenever I do the same in Visual Studio with the following statement:
#include "includedFile.h"
or
#include "include/includedFile.h"
It doesn't work and instead I get the error:
cannot open include file: 'includedFile.h'; no such file or directory.
Is there some box or setting that I have to tick? Or do I have to add each header as a dependency manually?
Here is the code for the class in question:
Public.h:
#pragma once
class Public
{
public:
static const int SCREEN_WIDTH=1000;
static const int SCREEN_HEIGHT=1250;
Public(void);
~Public(void);
};
Public.cpp:
#include "Public.h"
Public::Public(void)
{
}
Public::~Public(void)
{
}
How it is being included:
#include "Public.h"
I had this same issue going from e.g gcc to visual studio for C programming. Make sure your include file is actually in the directory -- not just shown in the VS project tree. For me in other languages copying into a folder in the project tree would indeed move the file in. With Visual Studio 2010, pasting into "Header Files" was NOT putting the .h file there.
Please check your actual directory for the presence of the include file. Putting it into the "header files" folder in project/solution explorer was not enough.
Go to your Project properties (Project -> Properties -> Configuration Properties -> C/C++ -> General) and in the field Additional Include Directories add the path to your .h file.
And be sure that your Configuration and Platform are the active ones. Example: Configuration: Active(Debug) Platform: Active(Win32).
You need to set the path for the preprocessor to search for these include files, if they are not in the project folder.
You can set the path in VC++ Directories, or in Additional Include Directories. Both are found in project settings.
By default, Visual Studio searches for headers in the folder where your project is ($ProjectDir) and in the default standard libraries directories. If you need to include something that is not placed in your project directory, you need to add the path to the folder to include:
Go to your Project properties (Project -> Properties -> Configuration Properties -> C/C++ -> General) and in the field Additional Include Directories add the path to your .h file.
You can, also, as suggested by Chris Olen, add the path to VC++ Directories field.
I found this post because I was having the same error in Microsoft Visual C++. (Though it seems it's cause was a little different, than the above posted question.)
I had placed the file, I was trying to include, in the same directory, but it still could not be found.
My include looked like this: #include <ftdi.h>
But When I changed it to this: #include "ftdi.h" then it found it.
If your problem is still there it's certainly because you are trying to compile a different version from your current settings.
For example if you set your Additional Include Directories in Debug x64, be sure that you are compiling with the same configuration.
Check this: Build > Configuration Manager... > There is problably something like this in your active solution configuration: Debug x86 (Win32) platform.
For me, it helped to link the projects current directory as such:
In the properties -> C++ -> General window, instead of linking the path to the file in "additional include directories". Put "." and uncheck "inheret from parent or project defaults".
Hope this helps.
I tried the other answers here as well, but my problem had nothing to do with the include paths or files missing incorrect #includes. I had two configurations, each set to the exact same include directories. One configuration could resolve the includes, the other could not.
After selecting my project and going to Project -> Properties, I selected both configurations through the Configuration dropdown -> Multiple Configurations... option. Comparing the two I found that C/C++ -> Language -> Conformance Mode was different. The "incorrect" configuration had a value of Default for some reason, and switching it to Yes or No allowed the paths to be resolved.
TL;DR: If you have one configuration with the same include directories but the other isn't finding the files, I suggest to try comparing the configurations.
If you've tried the other answers and your include file still can't be found, here are some additional debugging steps and sanity-checks:
Ensure that you are building to a platform that is supported by your code. (If not, consider removing this platform as a target)
Verify that the filename/path is correct. Modify your source code to #include the whole absolute path of the header file instead, and see if the file can be found now. If not, copy-paste the path from your source code into a command line to validate that the file exists at that full path with no typos. Open the header file to ensure you have read access. (Change the source code back when done.)
If you've already added the path to Additional Include Directories, try clicking the drop-down combo box for Additional Include Directories, and select <Edit...>. This will show you evaluated values of paths. (If it does not show the correct evaluated values, variables in your path might not be set. Click Macros>> to see variables.) Copy-paste the evaluated path into windows explorer to validate that the path exists.
Create a new empty C++ "Windows Console Application" project. Set just the one Include Directory, and #include just the one file in your main.cpp, and see if that builds.
I have a VS 2010 C++ project.
When I try to compile it, it tells me
Error 1 error LNK1104: File "C:\Users\MyUser\Desktop\project1\Debug\mysynth.lib" could not be opened. C:\Users\MyUser\Desktop\project1\subproject\LINK subproject
I have removed all dependencies from Linker->Input->, but it is still looking for the above lib.
Where else could this link be stated?
You can specify additional linker options in the configuration dialog. Look under the Linker | Command Line page. Perhaps the errant lib is specified there. In any case you can see there the command line that is passed to the linker and determine whether or not your lib file is there.
The easiest way to work out where they are coming from is to open up the project file in a text editor and search for the errant lib file. If the problem is in the project configuration, this tactic is guaranteed to succeed.
If you have removed everything from your project settings, and you are not passing the errant lib to the linker command line, then the other place where a lib file may be specified is in code. In a #pragma statement. It would look like this:
#pragma comment(lib, "mysynth")
Look in the properties explorer. Read the MSBuild documentation for the order that they are read. This is the most confusing part of going from VS2008 forward.
I am trying to link FMOD to my project, which I did very easily in the past in Visual Studio 2008.... So I have placed the fmodex_vc.lib and the fmodex.dll file in my project directory, added them to my project's solution explorer, then created a SoundMgr.h file which includes the fmod.h file
#include "include\fmod\fmod.h"
Where fmod has been placed in the include\fmod folder and opens ok if i right click on the above code and click "Open Document"...
But if I try to write any code at all, including a simple "using namespace FMOD" it tells me that it FMOD is undeclared or unidentified.... am I missing any step?
EDIT:
What the class looks like so far is:
#pragma once
#include "main.h"
#include "include\fmod\fmod.hpp"
#include "include\fmod\fmod_errors.h"
#include "include\fmod\fmod.h"
class SoundMgr{
void init();
};
void SoundMgr::init(){
FSOUND_Init (44100, 32, 0);
}
And the error is:
Error 1 error C3861: 'FSOUND_Init': identifier not found
And that's for any line of the sample code that I try import from this quick guide:
GameDev FMOD quick guide
I tried adding the library as an additional dependency in the Input section of the Properties/Linker and I get
1. fatal error LNK1181: cannot open input file 'fmodex_vc.lib'
Any of these errors ring a bell?
Don't you want fmod.hpp to get the c++ features?
you can include the headers path in C/C++ > General and library path to Linker properties and include the dll's in you project. In this case you have the files in you release/debug dir
Right so I eventually fixed it by removing the Additional Dependency in the Input section of the Linker and instead adding Include and Library directories in in Configuration Properties\VC++ directories.... Most articles I found advise to use the actual full path to the FMOD installation folder, but since I want this project to be portable and self contained, i created a "lib" and "include" folder in my project and put those files in them... (used the directories "\lib" and "\include" in the project properties which I am assuming links to the project folder, have never done this before but am hoping it won't cause dependency issues if I compile this on a different machine)...
I am having trouble getting my project to link to the Boost (version 1.37.0) Filesystem lib file in Microsoft Visual C++ 2008 Express Edition. The Filesystem library is not a header-only library. I have been following the Getting Started on Windows guide posted on the official boost web page. Here are the steps I have taken:
I used bjam to build the complete set of lib files using:
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete
I copied the /libs directory (located in C:\Program Files\boost\build-boost\boost\bin.v2) to C:\Program Files\boost\boost_1_37_0\libs.
In Visual C++, under Project > Properties > Additional Library Directories I added these paths:
C:\Program Files\boost\boost_1_37_0\libs
C:\Program Files\boost\boost_1_37_0\libs\filesystem\build\msvc-9.0express\debug\link-static\threading-multi
I added the second one out of desperation. It is the exact directory where libboost_system-vc90-mt-gd-1_37.lib resides.
In Configuration Properties > C/C++ > General > Additional Include Directories I added the following path:
C:\Program Files\boost\boost_1_37_0
Then, to put the icing on the cake, under Tools > Options VC++ Directories > Library files, I added the same directories mentioned in step 3.
Despite all this, when I build my project I get the following error:
fatal error LNK1104: cannot open file 'libboost_system-vc90-mt-gd-1_37.lib'
Additionally, here is the code that I am attempting to compile as well as a screen shot of the aformentioned directory where the (assumedly correct) lib file resides:
#include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations
#include <iostream> // for std::cout
using boost::filesystem; // for ease of tutorial presentation;
// a namespace alias is preferred practice in real code
using namespace std;
int main()
{
cout << "Hello, world!" << endl;
return 0;
}
Ferruccio's answer contains most of the insight. However, Pukku made me realize my mistake. I am posting my own answer to give a full explanation. As Ferruccio explained, Filesystem relies on two libraries. For me, these are:
libboost_system-vc90-mt-gd-1_37.lib
libboost_filesystem-vc90-mt-gd-1_37.lib
I must not have noticed that when I supplied the directory for libboost_filesystem-vc90-mt-gd-1_37.lib, the error output changed from
fatal error LNK1104: cannot open file 'libboost_filesystem-vc90-mt-gd-1_37.lib'
to
fatal error LNK1104: cannot open file 'libboost_system-vc90-mt-gd-1_37.lib'
Causing me to think that the error was persisting. This lead me to post some rather inaccurate information. Also, after reading that Filesystem requires two libraries, I now see the significance of the keyword stage for the bjam command. Supplying
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete stage
Causes bjam to place an additional directory, aptly named stage, in the boost_1_37_0 directory. This folder contains a folder named /lib, which has copies of all of the lib files in one place. This is convenient for Visual C++ because you can supply it with this single directory and it will take care of all of the dependencies.
boost::filesystem is dependent on boost::system, so you need both paths.
Part of the problem is you're using the boost libs out of the build directories instead of the install directory (the boost build process should create both). The install/lib directory has all the libs so you only need to specify one path.
The boost build process builds each library in its own directory. At the end it copies all those .lib files into one common lib directory.
Since you didn't specify an install directory as part of your build command (with --prefix=...), I believe the default is C:\Boost. Check to see if that directory is there and if so use C:\boost\include\ boost-1_37 for your include path and C:\boost\lib for your library path.
Last answer is right.
But you should find boost config file $BOOST\config\user.hpp and
uncomment this directive #define BOOST_ALL_DYN_LINK.
Now it begin use dynamic link with boost and it should works.
I think the real original problem is related to the default boost build process on windows which expects static linking of a library which will have a name beginning libboost_sytem<etc..>. The macro you need is
#define BOOST_SYSTEM_DYN_LINK
which makes ensures that the Boost.System library is dynamically linked. The dynamic library name is boost_system<etc...> as apposed the the static library libboost_sytem<etc...>
The bjam command line should have built all versions of all libraries. Still, when you build with
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete stage
(note the stage at the end) all libraries are copied to a common libs/ folder, so that MSVC's autolinking feature works when you only add this libs/ folder to your library path.
I do not know if bjam without stage still copies all those files to a single folder. If not, execute such a stage build to do this. If they are, well, sorry, configuration seems correct, maybe a minor typing error somewhere?
The error you have posted complains about file libboost_system-vc90-mt-gd-1_37.lib, but in the directory you have only libboost_filesystem-vc90-mt-gd-1_37.lib, right?
Look for libboost_system-vc90-mt-gd-1_37.lib. If you find it, add the corresponding directory to the library search path. If you don't find it, see if you have boost_system-vc90-mt-gd-1_37.lib instead (like I do), and try copying that to the desired filename.
I had this same problem, what you need to do is add the "lib" directory under the top level boost folder to the library path in Visual C++.
This most definitely solved the issue for me.