I have a fairly simple, multithreaded application that runs as a console app in c++, based mostly on calling external dlls. I need to add a Form to it, so I have created a new visual studio project (c++/CLR), and am adding my existing cpp and .h files to it. BUT, when I try to build, i get:
Severity Code Description Project File Line Suppression State
Error C1189 #error: <thread> is not supported when compiling with /clr or /clr:pure.
Severity Code Description Project File Line Suppression State
Error (active) #error directive: <mutex> is not supported when compiling with /clr or /clr:pure.
IS this how I should be adding a form? How can I get around this error?
Thanks.
Ah, solved. As here:
VC2008, how to turn CLR flag off for individual files in C++/CLI project
I need to turn off clr support on the single .cpp file.
Related
I've created a managed C++ log parser application using C++ vectors and Winforms. I want to add multithreading and Boost seemed like a better option than Winforms BackgroundWorker because I want to be able to execute my existing C++ function with each thread. I installed Boost multiple times following multiple different tutorials (lastly this one: https://levelup.gitconnected.com/the-definite-guide-on-compiling-and-linking-boost-c-libraries-for-visual-studio-projects-c79464d7282d) and I still have the same issue when I try to #include <boost/thread.hpp>
Error LNK1104 cannot open file 'libboost_thread-vc143-mt-x64-1_78.lib'
I don't know why it's looking for this library when I have Boost 1_79 installed not 1_78. My .lib file also has "mt-gd-x64" not just "mt-x64". I've already specified the correct file path to the library in Project->Properties->Linker->General->Additional Library Directories. I've also tried installing Boost via Visual Studio 2022 NuGet Package Manager. The lib file in that folder is also slightly off. "vc120" instead of "vc143". I've even tried changing the .lib file name to match the file name in the linker error exactly but when I do that I get more errors like LNK1104 cannot open file 'libboost_chrono-vc143-mt-x64-1_78.lib'
Do I just need to delete all my Boost files and download version 1_78 and try again? Why is Visual Studio looking for the wrong file name when it compiles? Is my #include statement wrong?
I ended up solving this problem by downloading boost 1_78, building it, and specifying that folder instead or the 1_79 folder. If anyone might know why the program was looking for 1_78 instead of 1_79 feel free to respond Also big thanks to George Gkasdrogkas who wrote the tutorial that worked best for me on how to install Boost. Tutorial is linked in the question :)
I use VS2012 (VC11), Boost 1.57, QuantLib 1.4. My goal is to make a Visual CLR project using these libraries in a separate solution than the original QuantLib solution. I started step-by-step to carefully include the libraries, but when I just added the line #include , it gave me the following error:
metadata operation failed (8013119F) : A TypeRef exists which should,
but does not, have a corresponding TypeDef : (OPERATORS_NOT_ALLOWED): (0x0100001b)
Anyone can help?
I have the following projects in a Visual Studio 2012 solution:
Native (no /clr) static lib project, compiled with /ZI for Edit And Continue.
C++/CLI DLL project, which references the above static lib.
The C++/CLI project builds with the following warning:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
If /OPT:NOLBR is added to the linker options of the C++/CLI project, the warning becomes:
warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
Any attempt to change the incremental linkage setting of the C++/CLI project doesn't change the warning (C++/CLI projects never link incrementally anyway).
I understand that I won't be able to use Edit And Continue in the C++/CLI project, because this is not supported. Indeed, changing /ZI to /Zi (disabling Edit And Continue) in the static lib project eliminates the warning, but I can't do that - other non-CLR consumers of that lib need to use Edit And Continue.
How can I get rid of this warning without disabling Edit And Continue in the static lib (and hopefully without maintaining separate build configuration for native and CLR users of the static lib)? I mean, is there any way to ask the linker to ignore the /EDITANDCONTINUE directive that is embedded in the referenced static lib (much in the same way that /NODEFAULTLIB can ignore /DEFAULTLIB directives)?
I have created a minimal VS solution that reproduces the described issue.
due to '/OPT:LBR' specification
This is a nonsense error message, that linker option is only effective for ARM binaries. This is simply a bug, using /OPT:NOLBR takes the sting out of it and you get the real warning.
Which is accurate enough, although it doesn't win any prizes either, you asked for Edit+Continue support in your static lib project but that is not available for a mixed-mode .NET assembly. The undocumented /IGNORE linker option is available to suppress warning messages but this one is ranked as an "unignorable warning" by Chapell.
You'll have to live with this warning as long as you don't want to change your static lib project. It is completely benign. You won't get it when you recompile it with /Zi.
There is no other way than to
disable "Edit And Continue" in the library
create a separate build configuration for "Edit And Continue (/ZI)" and "Program Database (/Zi)"
Of course: I am not aware that there is a predefined macro to determine between /ZI and /Zi... so you need to define your own preprocessor directive to distinguish between these configurations...
I had the same problem and found the only solution is to delete the .vcxproj and .sln files of the project and create the project again.
But then in an old copy of the same project I found a better solution: I changed in the projectname.vcxproj file the line
Profile true
to
Profile false
and LNK4075 warnings disappeared.
It had been the Visual Studio Profiler who had caused the troubles.
I've Win32 DLL application. Debug build is selected. I wrote such code:
#if DEBUG
fflush(logFile);
#endif
But fflush(logFile); is grayed out so I assume it will not be executed.
But i want it to be executed. Does it mean that in Debug DEBUG symbol is not defined? Where can I define it in VS2012?
Preprocessor definitions are defined under project settings as shown on screenshot (note _DEBUG there):
Note that in case of _DEBUG you want to check if it is defined at all, and not compare it (possibly missing definition) to zero. You want:
#if defined(_DEBUG)
or
#ifdef _DEBUG
By default, a Visual Studio C++ project will have the macro _DEBUG defined for a Debug project configuration. It will have the value 1, so you can test for it using #if or #ifdef.
But note that the macro starts with an underscore - if you want to use the name DEBUG (maybe you have existing code that uses that name), you'll need to add it to the project properties yourself (C/C++ | Preprocessor | Preprocessor definitions). Or you can put the following in a header that's included in every translation unit (maybe stdafx.h):
#if _DEBUG
#undef DEBUG
#define DEBUG 1
#endif
Every project has two builds: Debug and Release. Debug build have DEBUG defined, as if you defined using:
#define DEBUG
It enables, the code to get generated differently. The writers of code (functions, classes etc), may add additional diagonistics to aid in debugging. The Debug build is for debugging only, and you don't give this build (i.e. EXE generated with Debug build), to the customers.
Another build where DEBUG symbols is not defined, is for Release build. A release build is for optmized code, at code level, compiler setting level, and linker level. Most of diagonistic, asserts, debugging-aid feature will be disabled - so as to produce optimized executable.
Whomsoever who has written the above code, has written the same thing in mind. To let flush the file, only if debug build is running. You can comment the #if and #endif, and let fflush line compiled, or you can use Release build. It all depends on you.
By default, Visual Studio compiles a project to use the Multi Threaded DLL, found in the Visual Studio runtime. I want to compile my program using only /MT instead of /MD. Granted, that most systems already have this installed, and it's also available as a re-distributable.
When I change /MD to /MT, I get an error:
MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
And four or five similar errors.
To try and fix this I removed LIBCMT.LIB from the default libraries.
I then get the error:
libcpmt.lib(_tolower.obj) : error LNK2019: unresolved external symbol __calloc_crt referenced in function __Getctype
Removing MSVCRTD.lib from the default list leads to similar errors?
It should be noted that:
-This is an OpenGL project, using the glfw library.
-I am using the SOIL image library by lonesock for texture loading.
Without any further precise information, I would say your first problem is that you're somehow mixing release and debug versions of libraries. MSVCRTD.lib is the debug version of MSVCRT.lib.
Either you have some debug settings hanging around in your own projects, or you're linking against debug versions of libraries you're using.
Never ever mix debug and release versions. If you're lucky you get an error like this. In some rare situations all magically seems to work until it doesn't.