d3dx11.lib not found? - c++

I'm using Windows 8 / Visual Studio 2012, C++11 and Direct3D 11 for development.
I include the Direct3D libraries like this
#pragma comment(lib, "dxgi.lib")
#pragma comment(lib, "d3d11.lib")
#pragma comment(lib, "d3dx11.lib") // <-- error LNK1104: cannot open file 'd3dx11.lib'
#pragma comment(lib, "d3dx10.lib")
However, the linker can't seem to find the d3dx11.lib. After adding the path where the library is located to the 'Library directories' of the project, the linker still can't find those files. Even after I copied the lib files into the project directory itself, it doesn't work.
I installed the Windows 8 SDK as well as the DirectX SDK from June 2010. Am I missing anything?

When dealing with this myself, I started here:
Where is the DirectX SDK?
then - in about the middle of that page, reading about DirectXMath:
DirectXMath
It's pretty much just including the right header files and changing "D3DX" prefixes to "XM". Not quite that simple, but that's the general idea.
Your first program will probably have inclusions/usings like this:
#include <d3d11.h>
#include “DirectXMath.h”
#include “DirectXPackedVector.h”
using namespace DirectX;
using namespace DirectX::PackedVector;
struct mystruct
{
DirectX::XMFLOAT3 position;
DirectX::PackedVector::HALF packedValue;
};
Of course, it's not considered best practice to have "using namespace", but in this one instance I found that "DirectX::" on every line of my program was making my program almost impossible (for me) to read - so I went with the "using".
Good luck!

Probably you included bad path in properties, Instead "*DirectxSDK/Lib/x86", you included ""*DirectxSDK/Lib".

I was running into this issue as well using VS2010, but I just found the solution. You need to provider the Linker with the library file that you are having trouble with.
Project->Properties->Configuration Properties->Linker->Additional Library Directories
Then add the library file that you want into there. Worked for me, hopefully works for you too, and then you don't have to mess with DirectXMath and finding new tutorials for it.

Related

Use libraries inside injection DLL file

I'm working on the internal mod menu for one game and I want to use CPR library inside my DLL to get the latest version of offset from the server after injection. right now I get a static version of CPR package with vcpkg and move all .lib file and include file to my project and add them in my include and lib directories and use it like this :
#pragma once
#pragma comment(lib, "crypt32.lib")
#pragma comment(lib, "ws2_32.lib")
#pragma comment(lib, "zlib.lib")
#pragma comment(lib, "libcurl.lib")
#pragma comment(lib, "cpr.lib")
#include "cpr/cpr.h"
cpr::Response r = cpr::Get(cpr::Url{ "https://myurl.com/getoffset" });
cout << r.status_code << endl;
cout << r.text << endl;
string json= r.text;
It's work fine without any problem but as you can see it's a bit messy with all those "#pragma comment" so I tried to use a dynamic version of CPR so after compiling it I have 3 DLL files :
myMode.dll
libcurl.dll
zlib1.dll
the problem now is I must put "zlib1.dll" and "libcurl.dll" inside game folder near .exe file otherwise it won't inject; is there any way to locate them inside my DLL and tell DLL to use that location?
or just use it like this but remove this "#pragma comment" somehow and add the location for all of them in visual studio ?
Everything you need to know about DLL search paths is well documented here.
The easiest approach would be to just statically link with libcurl and zlib instead of using the DLL stub libraries. What's the downside of that?
Otherwise, all your dependent DLLs need to be in your EXE folder, the current working directory (usually the same as the EXE folder), a system directory (no!), or the PATH.
If your extension has an installer, then maybe it just updates PATH with your install folder of your DLL and all its dependencies.
As for the "messy" pragma comment statements. The standard approach is to add these via the Visual Studio project IDE. That gives you better control of the link search path so you don't have to dump all the stub .lib files in the same folder you build from.

Can't Get VS2019 Build Options Correct For OpenSSL in April 2020

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?

Best practice when producing a C++ static or dynamic library for others?

I'm providing a Microsoft C++ library (static and dynamic) for other clients in my company. My library has a few classes that depend upon functions located in common Windows DLLs whose import libraries aren't included in the project link settings by default.
Rather than add a new import library name to the linker section of every build configuration of my library each time a new dependency like this came up, I thought it would be better in terms of encapsulation of dependencies (and a bit more self-documenting) if I used #pragma comment(lib, ...) in the .cpp file of the class that depended upon a function from such a DLL, e.g.:
Foo.cpp:
#include <SomeWinLib.h>
#pragma comment(lib, "somewinlib.lib")
... implementation of Foo class ...
...but I found that this was causing link warnings/errors for clients of my library if they were also using SomeWinLib. After doing some reading on the subject, it seems that the recommended/best practice is to let the client who is linking in my library also link in the libraries it depends upon.
I still wanted this to be as automatic/painless as possible for the clients, so rather than just put a list of required import libraries in a readme.txt file (and then sit back and wait for the inevitable phone calls from frustrated developers), I'd just place the #pragma comment in the Foo.h header file. That way, clients would automatically link in the required library if they included the header file of a class that required it.
Foo.h:
#pragma comment(lib, "somewinlib.lib")
public class Foo
{
However, when I build my library, Foo.cpp includes Foo.h obviously, so it would seem that I need some kind of preprocessor "guard" around the #pragma comment line in the header file so that it's only seen by the preprocessor when clients include my header file.
Foo.h:
#if !defined(building_my_library)
#pragma comment(lib, "somewinlib.lib")
#endif
public class Foo
{
All of this seems like something that pretty much EVERY library must be doing, yet I don't see examples of this when I Google other open source Windows libraries. That makes me suspect I've missed something somewhere.
Does anyone know if I'm understanding the issues correctly, and if so, whether I'm over-complicating the solution?
Thanks!
Your last option is more or less what the boost headers do, except they also provide a preprocessor directive to explicitly turn off the auto-linking in case you want to control things yourself:
#if !defined(building_my_library) && !defined(no_auto_link_stuff)
#pragma comment(lib, "somelib.lib")
#endif
A solution that you might not have considered is to use runtime linkage to the DLL via LoadLibrary and GetProcAddress, removing the dependence on somewinlib.lib.

Cannot #include freeglut of OpenGL in Visual Studio C++ 2013

I want to begin programming with C++ OpenGl, and thus have downloaded freeglut to be included in my programn.
I have defined statically FREEGLUT_STATIC
Here is my source.cpp:
#include <GL\glew.h>
#include <GL\GLU.h>
#include <GL\freeglut.h>
#include "Source.h"
using namespace std;
int main()
{
return 0;
}
source.h
#define FREEGLUT_STATIC
But it does not work, the error is:
1>LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
It's worth mentioning that I have added the libraries directories to the project, and even when I type Gl/ visual studio 2013 automatically suggest the libraries and headers which means it knows the directory,
I have found the problem. I should simlpy do the following:
Right click on my project in Visual Studio, go to the properties, and then to VC++ Directories, click on "Library Directories" and then add a new path:
under the freeglut main directory in your hard drive, there is a folder called lib/x86/Debug, just add the full path and then apply that.
Your script should be executed properly.
The include works alright (otherwise you'd get an error at compile time, not at link time). The library file itself (freeglut.lib) seems to be missing. This SO question addreses your problem.
EDIT: Updated my answer because obviously just the binary for the lib is missing. Same link already given in a comment by swaldi.

Where is cmcfg32.lib?

I found a source code on MSDN about how to enable/disable privileges in C++
According to the source code, the linker must include cmcfg32.lib, but it can't be found...
I tried to compile without including that lib, it compiles without any error, but when I launch my program, it crashes with a fatal error.
So please, if you know which SDK contains cmcfg32.lib, let me know ;)
Thanks!
It looks (to me) like a minor error in the code. Delete the line:
#pragma comment(lib, "cmcfg32.lib")
Of, if you want the correct library linked automatically, change it to:
#pragma comment(lib, "advapi32.lib")
This code links for me without trouble, using the 6.0a version of the SDK. "cmcfg" googles as Connection Manager Configuration, no idea what that is or why it would be needed here.
Just delete the #pragma.