I have a Qt project and would like to use an external library that includes "afxstr.h".
Problem is that whenever I compile after linking to the lib and including their header, I get an error:
#error afxstr.h can only be used in MFC projects. Use atlstr.h
Of course, my project is not an MFC project and I can't use atlstr.h instead because it's not my library.
I'm looking for a quick solution!
I'm using VS2010.
The lib in question is the Interactive Brokers API.
The respective setting is Configuration Properties/ General, Use of MFC.
The compiler option implied from that is /D "_AFXDLL" when using MFC in a DLL.
As for linker options, curiously the explicit linking of windows import libraries (such as kernel32.lib) get removed.
Visual Studio seems to find the respective libraries automatically. However, the "Use of MFC" option is stored with the project file, so I can't say how it would translates to a custom build script.
The first include must be
#include <afx.h>
and you cannot include windows.h before that. Typically, that's the first include in stdafx.h if you use precompiled headers. Other than that, other MFC headers can be included freely as needed.
I doubt that this is the end of the story, getting MFC to play with anything is painful, and sometimes it's easier to give up :) A quick google reveals that there are solutions, but they involve additional code and are rather old.
well, you have already know this, just make it more clear:
.pro file add:
DEFINES += IB_USE_STD_STRING
avoid use MFC CString
Related
Right now I'm trying to create my first "real" project in C++ using Visual Studio 2019. I need to include a third-party library as a dependency. The instructions on the project homepage simply recommend to include all source/header files directly into the project. My understanding is that it's a bad practice, since the end result would look quite ugly in any VCS.
Thankfully, the library author also provided build scripts that call cl, lib and link with appropriate arguments and produce the coveted foo.lib. I added that file to dependencies in linker options and after some haranguing with compiler/linker options finally got it running.
To my distress, I realised that I've done all those manipulations in Release configuration, which prevented me from using the debugger. I then built the library with /MDd, fixed some compiler options... and got a bizarre compile-time error in vcruntime.h ( fatal error C1189: #error: _HAS_CXX17 and _HAS_CXX20 must both be defined, and _HAS_CXX20 must imply _HAS_CXX17).
At this point, I knew I was doing something terribly wrong, since including a simple library should't require so much manual knob-tweaking. What is the right, canonical way of including third-party dependencies in Visual Studio (and C++ in general)? Assuming the dependency isn't available on Nuget, vcpkg or somesuch.
As I understand from the stuff you did was on Windows. First of all I would recommend you try a linux distro. In windows it is possible to get lib files running, but not easy. It would help if you could send me a link to the library you are using.
The usual approach is to just stick those sources in their own directory and their own Visual Studio project (not solution). This can still build a foo.lib. You won't need many options for this.
Next, you just tell Visual Studio that your own project depends on that other project, and it will then link foo.LIB for you.
Having said that, it sounds like you try to build your two projects with different settings for the C++ version. VS2019 has good support for C++17 and experimental support for C++20, so you can choose. But you need to choose consistently for all your projects.
In larger solutions you can us a .vsprops file for that, which is like an #include for project files. A bit overkill when you have two projects, a lifesaver when you have 150.
It varies a bit how you include 3rd party libraries, sometimes 3rd party libraries have an installation and install themselves like under Common Components sometimes you have to do it manually.
E.g. YourSolution/3rdParty/foo/include
YourSolution/3rdParty/foo/lib
YourSolution/3rdParty/foo/lib/release
YourSolution/3rdParty/foo/lib/debug
Sometimes the libraries have different names then they may be in the same folder.
Once you have that structure go to your project's properties C/C++ and add the include under Additional Include Directories make sure you have configuration "All Configurations" here. Then go to Project properties/Linker/Input and the dependency for Debug Configuration and for the Release Configuration - since usually they are different libraries per configuration. e.g. release/foo.lib and debug/foo.lib (foo.lib foo-d.lib or whatever they are called).
Use the macros to make sure you get the right locations so that they are relative to your solution and project. It is not good having absolute paths. E.g. $(SolutionDir)3rdparty\foo\include
Disclaimer : I am not sure this is the "optimal" way to do it but that is the way I do it.
I'm trying to build my VS2012 C++ project using Boost Regex library. It seems that the linker does not find the library and gives the error:
error LNK1104: cannot open file 'libboost_regex-vc110-mt-gd-1_50.lib'
In "Project Properties:Linker:General:Additional Library Directories", I included a path which (within a subdirectory) contains a library named boost_regex.lib.
This was built by a 3rd party framework (FireBreath), and I shouldn't change it. How do I get VS2012 to use this library instead of looking for one under the name referenced in the error?
Firstly, what makes you so sure that the boost_regex.lib is the right one? Is it even for your compiler and version? I also doubt that it is for the debug variant of the runtime library. My guess is that you will have to build this for the compiler that you're using and properly install it, for which there are instructions at the Boost website. This might also imply rebuilding FireBreath for your compiler, assuming that's a C++ library, too.
Then, the code in Boost that detects compiler settings and then selects a library to link against is correct for normal setups. This code uses "#pragma comment(lib, ...)" to specify the lib to link with, so you should be able to find the code. There, you should also be able to detect the macros that turn this feature off. However, you are probably not fixing anything with that but rather you are creating more problems.
Substituting the library is not something you want to do. Instead:
Download Boost into, say, c:\boost
Open a VS command prompt, go into c:\boost and run bjam. When this is done, run b2. Wait.
Now go into your project and add c:\boost\stage\lib to the Additional Library Directories setting.
This will allow you to build the project.
I need some advice on my project. I am going to use various C++ libraries to accomplish different tasks. I am using Visual Studio 2008. To me, it seems to get a little out of hand when I add the actual source code of the library to my project's path.
It seems easier to just use the include files of the library, and just link precompiled binaries to my application. So my question is this. Is it better for me to include the source code of each library to my project, compile and link, or will it be better to just compile the libraries separately (or download a precompiled version) and link it to my program? Are there any pitfalls of the second way?
Thanks
If a library is available use it.
With C++ and windows you may have to rebuild the library if it was built with a different compiler, there are issues linking C++ libs between gcc/mingw and visual studio.
but in general there is no reason to add the source to your code base.
Depending on the particular library, you might want to be able to debug it. Just downloading precompiled libraries and no source might make that difficult.
I have been learning opengl for about 4-5 months now.
I am ready to stop using glut(a helper library that obfuscates many difficult / tedious aspects of opengl programming )
Problem is, I feel I have removed all refrences to glut.h, as well as all function calls within glut, but when I run my application it is still trying to link to glut32.dll.
Generally so I and others can learn for later,
How can I tell which libraries an excutable/source-code need and why(function/header wise), either before or after compile?
I am using VS2010 but cross compiling this on a linux box with g++
In this specific instance I don't have the dll listed as an additional dependency . But I do see glut.h in the extrenal dependencies folder...i just cant remove it
Thank you
Dependency Walker is your friend for examining the dll dependencies of compiled binaries.
The principal problem is of course, you have added glut.lib or glut32.lib to your project someplace. Its probably in the Project Properties > Linker Settings > Additional Libraries, or some source file contains a #pragma something like this :-
#pragma comment(lib, "glut32.lib")
Look at the linker properties for you project(s). The dll, or rather, the corresponding .lib should be listed there under "additional dependencies".
Edit:
By the way, including a header and linking a library (or a dll) are two different things. You may be including a header somewhere, but not linking to the corresponding library. In that case, the linker will give you an error. On the other hand, you may not be including the header, and not using the library at all, but you may still be linking to it.
In this case it seems like we have both. If glut.h is in the external dependencies folder then you must be including it somewhere in your code. Try using find-in-files to look for it. Or delete it from your system altogether and try to compile.
Every exe/dll has something called an Import Address Table (IAT) which is information stored in the PE (Portable Executable: window's executable file format) file's header about what dlls the loader needs to load when the module in question is loaded. You can use tools like PE Viewer or PE Explorer to view this information or write your own (this is more difficult). What you will see are libraries that are statically linked to your executable. If you don't see glut32.dll in any of those files, it is possible that it is loaded dynamically through LoadLibrary api in some other openGL library. I am not very familiar with openGL binaries, so I cannot confirm this for you.
If you have problems to find where glut.lib is hidden in the visual studio project options, open the .vcproj in a standard text editor and make a full text search.
I have a c++ and a c# project in Visual Studio 2008. The c++ project uses an API that was built in VS2005. I need that c++ project to reference the standard library files from VS2005. The order that the compiler searches the include directories keeps pointing to the include files from VS2008, specifically the vector file. It crashes the program when running in Release when it references the vector file from VS2008. How do I force the c++ project to use the include directories from VS2005?
This is a total hack, but you might be able to explicitly include a specific implementation of vector by replacing:
#include <vector>
...with:
#include "C:\Program Files (x86)\Microsoft Visual Studio 8.0\VC\include"
But if you need your VS2008 project to use an older version of the STL, then I smell something pretty bad. Perhaps your DLLs don't seperate the interface from the implementation?
If you want to use the VS2005 headers you really should build with VS2005. You might get things to work by fiddling around with the include file path, but I'd expect a lot of headaches. I'm sure it's not supported, and if the headers want to pull in anything from the CRT library (ie., what you're using happens to not be header-only stuff) it'll likely not work very well if at all.
Here are two alternatives you can try.
First, rename the VS2005 version of <vector> to <vector_vs8>. Add an include path to this directory, and change
#include <vector>
...to
#include "vector_vs8"
Second, change some project settings around to use ONLY VS8 includes rather than VS9 includes:
Project>Settings>Configuration Properties>C/C++>General>Additional Include Directories set to point to the include directories for VS2005. This will include ALL vs2005 files, not just <vector>
*Project>Settings>Configuration Properties>C/C++>Preprocessor>*Ignore Standard Include Path set to TRUE
If the program crashes in a release build, the problem is probably with your code rather than the library code, and reverting back to VS2005 is just sticking your head in the sand. Moreover the problem is likely be to do with the compiler code generation rather than the compiler library, so using a hybrid of VS2010 and VS2005 may not resolve the problem, and I would say is likely to introduce far greater problems. Optimisation often breaks code that relies on undefined behaviour, since the compiler may legitimately behave in a different manner. You should fix your code.
Perhaps a better quick-fix that using an old library is to apply selective optimisation: disable the optimisation specifically on the module that is giving you the problem. That will also help isolate the problem, and without optimisation set, that module can be more easily debugged in the debugger.
Also simply referencing a different header file is probably insufficient; you will also need to link the VC2005 library as well; otherwise the library and the header may mismatch. In short, do not use a 'solution' that is more complex and error prone than the original problem!