I'm working on a C++ project (VS 2010) using CPLEX.
I have included the required cplex libraries in the project settings as follows:
added the "additional include directories" under C/C++ > general
added the "additional library directories" under linker > general
added the .lib files as "additional dependecies" under linker > input
Everything compiles fine, however my problem is that intellisense still reports errors (red squiggly underlines) such as "cannot open source file" in the #include line, and "identifier undefined" when using variable types defined in the CPLEX library.
The only difference with other projects that don't have this behaviour is that this time I have used windows environment variables in setting the include path, i.e. the library directories and include directories are defined similar to: %CPLEX_STUDIO_DIR%\cplex\include
I have set it like this so that I can build this project on different machines without messing around in the project properties. Since CPLEX is installed separately, using relative paths to specify additional directories is not really an option.
I'd like to repeat that the project compiles, it's only the intellisense errors that are bothering me.
I know I can turn off the intellisense error reporting, but if someone has a workaround for this I'd love to hear about it.
Kind regards,
This problem is known to Microsoft:
http://connect.microsoft.com/VisualStudio/feedback/details/779874/intellisense-cant-handle-using-environemt-variable-in-include-path
The only way I know of to avoid it is to manually enter the full literal path. The bug is marked "deferred" which I think means Microsoft has regarded it not serious enough to be fixed soon.
The solution is to replace %CPLEX_STUDIO_DIR%\cplex\include with $(CPLEX_STUDIO_DIR)\cplex\include. This is the syntax Visual Studio uses for its built-in variables such as $(VCInstallDir), but it also works for environment variables (so long as they don't have the same name as a built-in variable) and is recognised by intellisense as well as the compiler.
(I realise this is an old question, but it ranks highly in search results so it could help others even if not the original poster.)
Related
I had built a c++ dektop project with VS17.
Now due to certain requirements, I needed it to migrate to VS19.
After making changes to compile my project with VS19, I am seeing many errors like below:
C3646 'OVERRIDE': unknown override specifier
C2039: 'wstring': is not a member of 'std'
I found this link - https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c3646?view=msvc-170
but could not find it useful to fix my issue.
I am looking for an easy fix, like if there is a way to use VS17 c++ compiler in VS19.
Rather than going back to the old compiler, you might be better off tackling the errors one-by-one:
OVERRIDE: is probably defined as macro somewhere in your project. Find out, what value OVERRIDE is being resolved to. Put the cursor into the word OVERRIDE to get the value. It could be that the respective include file is not properly included for some reason. Does your old project include a forced include for global definitions?
wstring: to be recognized as std::wstring, you have to include <string>.
Check your UNICODE settings. They determine the usage of 8-byte vs. multi-byte characters for strings. Look at Configuration Properties / Advanced / Character Set in the solution properties.
I'm trying to import libuv into my CMake project so I can link it. I have libuv 1.12.0 installed from here and I placed it in C:\Program Files\libuv\.
project(tls-server LANGUAGES C)
set(LIBUV_ROOT_DIR "C:\\Program Files\\libuv")
add_library(libuv SHARED IMPORTED)
set_property(TARGET libuv PROPERTY IMPORTED_LOCATION "${LIBUV_ROOT_DIR}\\libuv.dll")
set_property(TARGET libuv PROPERTY IMPORTED_IMPLIB "${LIBUV_ROOT_DIR}\\libuv.lib")
add_executable(tls-server "${CMAKE_SOURCE_DIR}/src/main.c")
target_link_libraries(tls-server libuv)
However, given the above code I am still getting undefined symbol errors in Visual Studio:
How can I fix this? I believe the paths are all correct. I'm also using Windows 10.
Never hardcode library paths or names like this in CMake.
Instead use the find_library command, which does a decent job of notifying you early if something is wrong with the provided library.
On Windows in particular, since there are no default locations where libraries are located on the system (something like the /usr/local/lib on *nix systems), you may want to provide an additional customization point for the library's location. I personally like to use environment variables for this, but a normal CMake option will also do:
project(tls-server LANGUAGES C)
find_library(LIBUV_LIBRARIES NAMES uv libuv
HINTS $ENV{LIBUV_ROOT})
add_executable(tls-server ${PROJECT_SOURCE_DIR}/src/main.c)
target_link_libraries(tls-server ${LIBUV_LIBRARIES})
Note that CMake in general never takes care of copying runtime dependencies to the correct place! That is, if libuv was built as a .dll, you must ensure that that .dll is in the correct path when running the program.
You can of course manually insert a copy command in CMake for getting all the dlls into place, but that can be quite cumbersome. Unfortunately there is no more comfortable solution for this problem right now.
Using imported targets here is possible, but really only pays off if you need to pass on more complex properties to the depending target. In my experience, imported targets work best if the dependency provides a fully-fledged package config file. Writing imported targets manually is often not worth the trouble in terms of additional complexity.
I finally managed to solve the issue.
Firstly I reinstalled the binaries from the target library (libuv). Then, I made sure that my cmake was generating x64 project files by using cmake -G "Visual Studio 14 2015 Win64". That was sufficient to get rid of the undefined symbols error. Then all I needed to do was copy the libuv.dll file to the same directory as the executable file, and everything ran fine.
If anyone knows why this error occured, please comment so you can help out other people in the future target the cause of the error better.
When I open a generated solution+project file, I get the following warning for each platform I have in the project file:
path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.
some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.
My question is, what does '[some_platform, 0]' really mean?
Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?
This is a C++ project if that matters.
Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?
Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).
I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.
Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?
Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here:
Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.
Hope this will help you solve the problem.
I'm having difficulties trying to compile an opensource framework (EmulationStation) in VS2015 on Windows. I've never used any of the tools before, apart from Visual Studio - so please forgive me if these are some obvious mistakes.
The guide says i need to do like this:
Boost (you'll need to compile yourself or get the pre-compiled binaries)
Eigen3 (header-only library)
FreeImage
FreeType2 (you'll need to compile)
SDL2
cURL (you'll need to compile or get the pre-compiled DLL version)
(Remember to copy necessary .DLLs into the same folder as the executable: probably FreeImage.dll, freetype6.dll, SDL2.dll, libcurl.dll, and zlib1.dll. Exact list depends on if you built your libraries in "static" mode or not.)
CMake (this is used for generating the Visual Studio project)
(If you don't know how to use CMake, here are some hints: run cmake-gui and point it at your EmulationStation folder. Point the "build" directory somewhere - I use EmulationStation/build. Click configure, choose "Visual Studio [year] Project", fill in red fields as they appear and keep clicking Configure (you may need to check "Advanced"), then click Generate.)
This is how my CMake looks like (it says generating done)
I get alot of compilation errors in visual studio when trying to build though:
1) Cannot open include file: 'curl/curl.h': No such file or directory (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMetaDataEd.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\HttpReq.h
Where do I get this header file from?
2) 'round': redefinition; different exception specifications (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMenu.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\Util.h 18
I have a lot of these errors with round. Am I missing a reference to a library?
Another screendump of some of the errors from VS2015:
Hope someone can point me in the right direction.
I am currently in de same boat as you, trying to get ES building under MSVS2015.
I am also very green, so hopefully others chime in as well.
Regarding the 'round' errors, apparently the MS compiler has no knowledge of these. For this issue, and some others, the newer ES fork by Herdinger has fixed this.
As this is currently the most active ES branch out there, and has the explicit goal of consolidating at least some of the backlog of PRs from the original Aloshi git, I would suggest you use this one.
In issue #4, there is some more information on building in recent VS versions. There is also a link for the precompiled cURL libs, including the header.
Having gone that far, I am sad to say that I still do not have a succesfull build as of yet. Compiling is no problem, however linking gives me a LNK2005 error.
Hope this helps a bit. Let me know how you fare.
I am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example: