When the cuda_test.cu file is not included in the project, the code runs fine.
When such a file is included, I receive the following error message
mfcs100u.lib(dllmodul.obj) : error LNK2005: DllMain already defined in MSVCRT.lib(dllmain.obj)
cuda_test.cu has the following header files, a global function and a wrapper.
#include <cuda.h>
#include <cuda_runtime.h>
#include <device_launch_parameters.h>
So I am not sure what causes this problem.
After some research, it seems this problem is fairly common and has
fixes. But this starts giving trouble in a different part of the code. ("StdAfx.h" is included in all .cpp files, if this information is relevant).
It is a huge project written in C++ and I am trying to parallelize some parts of it.
Some help will be hugely appreciated. I can give extra details if needed.
You need to make sure that all parts of your app link against the same runtime.
In Solution Explorer, right click your .cu file and select Properties. Go to CUDA C/C++ > Host and make sure that Runtime Library is set to the same as for the rest of your project.
Related
I use MSVC2017 (with MSVC2013 toolchain, if it's matters).
So, I have created new solution with "static lib" project and a console app. At this step it works.
Now, I changed some project's paths for the lib project:
Output directory: $(SolutionDir)BuildDebug
Intermediate directory: $(OutDir)\Debug
I added following includes into pch.h:
#include <windows.h>
#include <inttypes.h>
#include <cstdlib>
#include <stdexcept>
I added reference to my lib and lib's include dir inside console app. Now Studio cannot compile my project, showing a lot of errors about
error C2061: syntax error: identifier 'LONG'
and related.
I found that there is no .pch file anywhere.
I also created test solution with same static lib alone and changed same paths. It seems to compiling successfully, but Intellisense underlines "LONG" with red, saying "it's undefined".
May be someone faced the same problem.
Update: I just tried to create a new solution. I added static lib project, then I added simple file with single function int func(LONG v). It seems to compile. But then I add console app to the solution, link it against static lib, and it's not compile, saying that
error C2065: 'LONG': undeclared identifier
Update 2: I've found that static lib files don't see <windows.h> added into precompiled header. So I included it into my header directly and added typedef struct IUnknown IUnknown; before windows.h, because of new error related to IUnknown. It seems to work. But I still don't understand what is going on.
"Pre-compiled headers" are a build-speed optimization. If they're giving you problems, you can always turn off their use temporarily. When they're turned off, the .pch is no longer used, but the .h is still used.
I expect you'll still have the missing LONG, since it's not even in the .h
For your sanity, it might be useful to use explicit names for your precompiled .h. I'm not sure if VS2017 already uses pch.h by default, or it it still uses stdafx.h. Either way, that's just a default. If you want, you can also rename them to staticlib.h/.pch and executable.h/.pch to avoid confusion. The compiler has no default name for the pch; it relies on compiler switches /Yc (create) and /Yu (use).
I am getting a linker error, I'll post it at the bottom. The goal is only to build the example SSL client from boost.
The overall question is just to find the simplest c++ way to download some xml from https://classic.wowhead.com/item=19351&xml
Edit: The problem has evolved as I've continued to work on it. I now realize that I had no idea how to use a static or dynamic library or how either worked. I know a little now.
I've built OpenSSL following this youtube video verbatim and it seems to have built properly. https://www.youtube.com/watch?v=PMHEoBkxYaQ
I'm now using the shorter example https://stackoverflow.com/a/7577229/2247872 and finally got it working which has helped enormously in identifying where the other errors are. I had to be really careful that I was using x86 Debug for everything and then added D:\out\lib\x32\Debug\include to my include directories, d:\out\lib\x64\debug\lib to my linker libraries, and libssl.lib and libcrypto.lib to my additional dependencies. One thing that was helpful is that if #include wasn't underlined by Visual Studio I knew I at least had the include directory set correctly.
I've made two copies of my program, one uses static linking the other dynamic linking. To get the dynamic linking one to work I had to copy the libssl-3.dll and libcrypto-3.dll files in to the same place as my executable.
Right now I'm still fighting with boost on the static one.
#include <boost/beast/core.hpp> //all of these are fine
#include <boost/beast/http.hpp>
#include <boost/beast/version.hpp>
#include <boost/asio/connect.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <openssl/ssl.h>
#include <openssl/conf.h>
//#include <boost/beast/ssl.hpp> //this line is giving me 196,429 errors.
//#include <boost/asio/ssl/error.hpp> ////this line is giving me 196,429 errors.
//#include <boost/asio/ssl/stream.hpp> //this line is giving me 196,429 errors.
Original Post:
I found similar questions on SO but the names of the OpenSSL libraries have changed and I need a current answer to setting up my MS Visual Studio 2019 project properties properly.
I do not need to build these files (I don't think). All I want to do is get the boost example here https://www.boost.org/doc/libs/master/libs/beast/example/http/client/sync-ssl/http_client_sync_ssl.cpp working.
Question 1: Which of the options from https://wiki.openssl.org/index.php/Binaries or https://slproweb.com/products/Win32OpenSSL.html do I want? For example I don't understand the difference between a pre-compiled build without external dependencies to VS2019 or the one on that bottom pre-compiled build with external dependencies to VS2019. My original choice was the one from the 2nd website that said 1.1.0L "this is the standard version for x64".
I chose the option to install the library files in the Windows System directory. I see files named
c:\windows\system32\libcrypto.dll
c:\windows\system32\libssl-1_1x64.dll
I added C:\Windows\System32 to my path environment in windows and restarted the computer.
In VS project properties:
My C/C++ --> General --> Additional Include Directories are:
d:\cpp\boost_1_72_0
d:\OpenSSL-Win64\include
My Linker --> General --> Additional Library Directories
d:\openssl-win64\lib
d:\openSSL-win64\lib\VC
d:\openSSL-win64\lib\VC\static
c:\windows\system32\
d:\opensll-win64\StaticDLLsIGuess (this is a directory I put files in from a 2nd attempt to solve the problem, by downloading two files from https://indy.fulgan.com/SSL/ but they need in ".a"
d:\cpp\boost_1_72_0\stage\lib
In Linker --> Additional Dependencies I tried to list:
libssl.lib
libcrypto.lib
But when those were there I got a different, simple error saying "libssl.lib" couldn't be found which I found baffling as pretty much my entire computer is in my build options. So why that is happening is question 2. Same thing for
c:\windows\system32\libssl-1_1x64.dll
I know that file is there, but when I put libssl-1_1x64.dll in additional dependencies I get a link1104 error that it's not found even though c:\windows\system32 is in additional library directories.
Question 3 is what libraries do I actually need? There are libraries in my system 32 directory, libraries in D:\OpenSSL-Win64\lib, and libraries in D:\OpenSSL-Win64\lib\VC
This is the actual error I'm getting but I cannot interpret what linker error messages actually mean.
Severity Code Description Project File Line Suppression State
Error
LNK2019 unresolved external symbol _CONF_modules_unload referenced in function "public: __thiscall
boost::asio::ssl::detail::openssl_init_base::do_init::~do_init(void)" (??
1do_init#openssl_init_base#detail#ssl#asio#boost##QAE#XZ) PreparedParser
D:\cpp\PreparedParser\PreparedParser\PreparedParser.obj 1
Edit: I am still in the process of trying to fix this myself, and I'm realizing that part of the problem is that I had no understanding of the difference between a dynamic and static library. I'm trying to figure that out now. Also, https://www.youtube.com/watch?v=PMHEoBkxYaQ is a video on how to compile OpenSSL and I'm doing that.
Edit April 18 11am: Side questions: If I download a .lib from somewhere, how do I put it in my program? Do I #include the lib file? Do I add it to additional dependencies? How do I know what functions are in it? How is it different for .dlls?
Currently running into an issue where Winsock.h is already included in a header file elsewhere in my project...
Header not directly included:
# if defined(_WINSOCKAPI_) && !defined(_WINSOCK2API_)
# error WinSock.h has already been included
# endif // defined(_WINSOCKAPI_) && !defined(_WINSOCK2API_)
So that when I try to build, I get a the error "C1189 Winsock.h has already been included" (from the defined error message in the above piece of code).
However, I need to be able to use parts of the PSAPI to obtain memory usage information about the current process. I tried to include in my other file...
My .cpp File:
#include <Windows.h>
#include <Psapi.h>
...
SIZE_T getMemoryInfo() { // The function that needs the includes
PROCESS_MEMORY_COUNTERS pmc;
SIZE_T memoryUsed;
GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc));
memoryUsed = pmc.WorkingSetSize;
return memoryUsed;
}
After researching I then tried using WIN32_LEAN_AND_MEAN to try to get rid of the Winsock.h include, which works, but now when I try to use PROCESS_MEMORY COUNTERS I get an undefined symbol error...
"LNK2019 unresolved external symbol GetProcessMemoryInfo referenced in function..." and "LNK1120 1 unresolved externals [in myFile]"
I expect that I need to figure out how to include the actual header files I need, but the Windows docs do not say (and Wikipedia says that most of the child headers cannot be individually included, so that's probably an issue).
#define WIN32_LEAN_AND_MEAN
#include <Windows.h> // Windows specific libraries for collecting software metrics.
#include <Psapi.h>
I've been trying to figure this out for a full day, any help would be appreciated as Windows Docs are pretty unhelpful and I am thoroughly frustrated. I apologize if it is a stupid question, but I frequently struggle with includes.
Finally figured it out.
Apparently the psapi.lib wasn't automatically being linked to by Visual Studio (despite the fact the Windows util libs are...). You have to go into properties/linker/input and manually add the library as a dependency. If it can't find the library location, add directory manually in C/C++ as a search directory.
You do have to have #define WIN32_LEAN_AND_MEAN as well.
Hope that helps, if anyone needs help with this in the future, just comment here.
Credit for the solution goes to #RbMn and #Scheff, thanks guys!
I've been using code blocks for a long time, but never really made my programs into actual code blocks projects. I tried to do it today, and I kept getting errors due to code blocks not recognizing my files. Here is what I have : ---->
CodeBlocks Include Error
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file. So I can only guess code blocks is not properly handling the files.
I would love if someone could help me out as to why this is happening.
Thanks a ton in advance :)
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file.
That's because they're not. You #included neither iostream nor class.h in menu.cpp, so you can't access the declarations therein.
Note that Code Blocks (just like any properly set up build tools) will compile each cpp file separately. This means that not only will it compile menu.cpp as part of the compilation of main.cpp (because you include it), it will also compile it on its own. In the latter case the includes from main.cpp will not be available, so menu.cpp needs its own includes.
This also means that once it does compile (i.e. once you added the includes), you'll get a linker error because the definitions from menu.cpp are now defined twice (once in main.o -- because you included menu.cpp in main.cpp -- and once in menu.o). That's the reason why you should never include cpp files into each other.
PS: This is unrelated to your problem, but it's considered bad practice to use using namespace in a header file. You should put that in your cpp files instead (if you want to use it at all). You should also put the #include <iostream> in those files where you actually need it, rather than the header file.
I'm trying to write a .dll library for .dll injection purposes. And because of this fact, it must have a routine called DllMain, since this is what will be used as the entry point. I think my problem may be stemming from the fact that I'm linking in a static library that I've wrote which utilizes a threads and mutexes from afxmt.h. Because somewhere down the line, the inclusion of this is causing the linker to link from mfcs100ud.lib which apparently contains its own version of DllMain.
Here is the file that is giving me trouble:
dllmain.cpp
#include "stdafx.h"
#include <stdio.h>
#include "NamedPipeLogger.h"
static CNamedPipeLogger m_PipeLogger("Log.txt");
BOOL APIENTRY DllMain(HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved)
{
}
Here is the stdafx.h file that dllmain.cpp is including.
stdafx.h
#pragma once
#define _AFXDLL
#include <Afx.h>
#include "targetver.h"
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
Here is my Error message:
Error 32 error LNK2005: _DllMain#12 already defined in
dllmain.obj D:\xxxxx\xxxxx\xxxxxx\mfcs100ud.lib(dllmodul.obj)
Am I just screwed here because I cannot change the name of my Dll entry point to something other than DllMain?
In many cases this is caused by having _USRDLL in the preprocessor settings, where it should be _LIB. This has to do with 'MFC extension dlls' which I don't think anyone still makes today, yet the VS wizard seems to assume you do want to use this when you check 'Use MFC' in the wizard.
Recently, I experienced the same or a similar issue, and found a solution.
Background
I have an MFC project in Visual Studio 2013 Pro, which generates a DLL. I have several .c modules in the project, which I'm able to do by conditionally specifying the 'extern "C"' construct, disabling precompiled headers for those C files, and - in my case - disabling inherited forced includes, which was pulling-in stdafx.h from the project defaults.
Problem
One day, after having used this method successfully on several C files, when I'd try to add just one more, I'd get the following error.
1>Link:
1> All outputs are up-to-date.
1>mfcs120d.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)
1> Creating library C:\path\to\project\build_dir\myproj.lib and object C:\path\to\project\build_dir\myproj.exp
1>C:\path\to\project\build_dir\myproj.dll : fatal error LNK1169: one or more multiply defined symbols found
1>
1>Build FAILED.
Solution
I resolved this by implementing "Solution One" from Microsoft Knowledge Base article Q148652, "A LNK2005 error occurs when the CRT library and MFC libraries are linked in the wrong order in Visual C++". This forces the linker to link the libraries in the correct order.
Steps:
Right-click the project, choose Properties.
Ensure you're making changes for All Configurations, and All Platforms.
In the left pane, browse to Linker → Input.
In the right pane, pull down Additional Dependencies, choose <Edit...>.
Add mfcs120d.lib.
Based on the Code Project article Solve error LNK2005: _DllMain#12 already defined in msvcrtd.lib(dllmain.obj) in MFC Projects", I figure I might have to add another library to that list someday, but this much works for me for now.
Well, I guess I threw in the towel on this one (sort of). I was able to at least get by all my problems. I just had to stop using some of the Microsoft classes.
I touched on this in the problem description, but I recall starting to have difficulty with compiling as soon as I started including:
#include <afxmt.h>
#include <afxwin.h>
So I went through and figured out what exactly I was using that required these includes. I was using the AfxBeginThread() method, and the classes CMutex and CCriticalSection. So I figured maybe if I could just get away from any of the proprietary windows stuff that maybe my problems would go away. That means removing all includes of , , and and then address the compilation errors with more standard c++ code. Here is what I did:
Instead of using AfxBeginThread() I used CreateThread().
Instead of using CMutex and CCriticalSection I used the CRITICAL_SECTION structure with its accompanying routines.
After this I was able to compile the .dll and it worked fine.
I got the error when I have moved #include afxdllx.h from dllmain.cpp to StdAfx.h. My project works without this include also