delay load DLL error (module not found) - c++

I am working on Visual Studio 2010 Express and I have a question concerning external DLLs.
I am using a DLL.
My question is: why do I get an error (0xC06D007E: Module not found) unless I put the .dll file in my project file.
To be specific, I use FFTW as an external library (a fast Fourier transform library). I followed the procedure: adding the .h file to the project; setting the proper linker properties:
I have added the fftw library path to "répertoire de bibliothèques supplémentaires", in the "general" tab of the linker property tab (sorry, it’s in french!)
I have added the name of the .lib file in the "Dépendances supplémentaires" field and the name of the .dll file in the "Chargement différé des DLL" field, both in the "entrée" (input) tab.
I have tried to fix things without changing the location of the dll file. I did not succeed.
Does someone have a suggestion?
Thanks
In a rough translation, "répertoire de bibliothèques supplémentaires" could be "directory containing additional libraries", "Dépendances supplémentaires" ~ "other dependencies" and "Chargement différé des DLL" ~ "DLL delayed loading" (not sure of this one).

This is a runtime issue. All the IDE settings that you discuss relate to the compilation and linking. But your issue arises at runtime.
DLLs are loaded at runtime and the system looks for them using the Dynamic-Link Library Search Order. Clearly you need your DLL to be found by that search. The simplest, and usually the preferred, way to achieve this is to place the DLL in the same directory as the executable.

Related

Why are C++ debug symbols mismatched when generated in the same Visual Studio solution?

Something is wrong with my Visual Studio 2019 project configuration and I have run out of ideas to check. I have 3 native C++ shared libraries (A, B, C) that all sequentially stack on each other. B depends on A. C depends B. I then link all 3 to an executable. So the final stack looks like A->B->C->Executable. All of the libraries and executable live within the same Visual Studio solution. All of the code is mine. The solution file was generated by CMake.
I can set breakpoints and debug into A, B, and the executable just fine. I cannot step into library C because the symbol file will not load. The Modules window says it "Cannot find or open the PDB file." The search path does include the project output folder. When I manually attempt to load the autogenerated library_c.pdb file I see a pop up error stating "A matching symbol file was not found in this folder."
I have tried deleting everything and recreating the environment from scratch. I have compared all the project settings between library C and the other debuggable libraries but found no discernable differences. My internet searches all say how to manually load symbols or indicate that the error is because the symbol don't match. I have not found any that suggest how or why the autogenerated pdb would not match the corresponding lib or dll when built.
Given this situation, what would you investigate next? What could cause the generated symbol file to be mismatched?
EDIT: drescherjm suggested I double check timestamps. Windows Explorer lists the "Date modified" as being identical. However, if I right click on each file and open properties I get an interesting abnormality. The "Created" timestamp of the good working files all have a date and time (HH:MM:SS). The bad library_c.pdb lists a date with no timestamp. Instead of a timestamp it says "XX minutes ago." I'm not sure what this means but it is a difference.
The CMake file for library C (called foo_client here) has this snippet.
add_library(foo::foo_client ALIAS foo_client)
set_target_properties(foo_client PROPERTIES EXPORT_NAME client)
The executable's target name in CMake is foo_client_exec. For a reason unknown to me this triggers a corrupt foo_client.pdb file. By using dbh I dumped all the source files (dbh foo_client.pdb src) referenced in the .pdb file and confirmed the list was missing everything from the foo_client library. However, it somehow referenced files from the executable. Let me repeat that oddity to emphasize it. The exectuable's files were somehow referenced in library's .pdb., foo_client.pdb. I have no idea how the chain of binaries could be propagated backwards from executable back into the library.
If I renamed the executable to anything that did NOT start with "foo_client" as a prefix then the .pdb file was generated correctly and only referenced the foo_client files. It appears that Visual Studio 2019 and/or CMake 3.15 was doing some kind of naming pattern match that caused the source files of the executable to replace the libary's files in the generated .pdb.
Despite the corrupted .pdb file the library performed without issue when linked into any executable. Whatever the root cause of the problem is it appears to be isolated to the generation of the .pdb file. Everything else works as normal as far as I can tell.

1>LINK : fatal error LNK1104: cannot open file

I am trying to add external libraries to my project but I always get this error
LINK : fatal error LNK1104: cannot open file 'C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\lib\x86.obj'. I was following these instructions:
(I was given these instructions )
The LpSensor library contains classes that allow a user to integrate LPMS devices into their own applications. The standard library is a Windows 32-bit C++ library for MS Visual C++ (express) 2010. Should you require a binary of the library to work on another operating system or 64-bit applications, please contact LP-RESEARCH.
Compiling applications that use the LpSensor library requires the following components:
Header files (usually in C:/OpenMAT/include):
LpmsSensorManagerI.h Contains the interface for the LpmsSensorManager class.
LpmsSensorI.h Contains the interface for the LpmsSensor class
ImuData.h Structure for containing output data from a LPMS device
LpmsDefinitions.h Macro definitions for accessing LPMS
DeviceListItem.h Contains the class definition for an element of a LPMS device list
LIB files (usually in C:/OpenMAT/lib/x86):
LpSensorD.lib LpSensor library (Debug version)
LpSensor.lib LpSensor library (Release version)
DLL files (usually in C:/OpenMAT/lib/x86):
LpSensorD.dll LpSensor library (Debug version)
LpSensor.dll LpSensor library (Release version)
PCANBasic.dll PeakCAN library DLL for CAN interface communication (optional).
ftd2xx.dll The FTDI library to communicate with an LPMS over USB.
To compile the application please do the following:
Include LpmsSensorManagerI.h.
Add LpSensor.lib (or LpSensorD.lib if you are compiling in debug mode) to the link libraries file list of your application
Make sure that you set a path to LpSensor.dll / LpSensorD.dll, PCANBasic.dll (optional) and ftd2xx.dll so that the runtime file of your application can access them.
Build your application.
I am using MS Visual Studio 2010 express 32-bit.And this is what I have done:
1) Project/Properties/Configuration Properties/C/C++/General/Additional Include Directories path---C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\include
2)Project/Properties/Configuration Properties/Linker/General/Additional Library Directories---C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\lib\x86
3)Project/Properties/Configuration Properties/Linker/Input/Additional Dependencies---C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\lib\x86
4) Project/Properties/Configuration Properties/VC++ Directories/General/ Include Directories path---C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\include
5) include "LpmsSensorManagerI.h"
I have tried to add quotes around the paths but it did not help.I have no clue why I am getting this error.
Does anyone know what I am doing wrong?
Thank you
It seems you have mistakenly added
" C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\lib\x86 " to the additional dependencies under
" Properties/Linker/Input/Additional Dependencies- "
In this section you should simply list your additional library names, such as
" LpSensor.lib "
The path " C:\Users\Lubdmila\Desktop\OpenMAT-1.3.4\lib\x86 " is already set in " Properties/Linker/General/Additional Library Directories--- " for the linker to look for.
It works now. I created a new project did the same steps but I changed step 3 as harry 268 advised and then I added path to dll files.
Here's the link to the solution: How to add a path to dll files
Visual Studio: how to set path to dll?
In my case I had fatal error LNK1104: cannot open file 'C:\Users\..\proj.exe'
in order to solve this issue, I just copied whole proj folder and renamed it. and that is working now

Unresolved external symbol when linking to third party libraries from UE4

EDIT:
Updated post to avoid linking to third party sites and to collect all required information here.
Any information is appreciated. If you need more info, please inform me and I will edit the post with the new details.
Here is some useful information to start with.
Errors.
Source code.
I am trying to use a third party SDK consisting of one lib file and essentially one header file. I manage to get the intellisense to work, but I get linker errors even though I have modified my project's build.cs file to add the library path.
public OculusTest(TargetInfo Target)
{
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore" });
// Add static libs
PublicAdditionalLibraries.Add(Path.Combine(ThirdPartyPath, "RPLidar/Libraries", "rplidar_driver.lib"));
// Add a path with the .h that has the function definitions
PublicIncludePaths.Add(Path.Combine(ThirdPartyPath, "RPLidar", "Includes"));
}
I also checked if I was missing something, but in a standalone C++ project I use the same files and only the same files and it does work. The files in question are
RPLidar.h and rplidar_driver.lib
As such I assume the error is in me failing to tell the Unreal compiler where to find the lib file.
Thank you in advance for all information regarding this way too stubborn error.
I finally found my error.
After checking that the same version of VSC++ was used to compile both programs and that I checked that it was in the correct configuration I changed one extra thing that made it all work out.
Instead of compiling to a multi threaded LIB file, I compiled the code as a DLL file.
I did it by opening the LIB project properties and going to C/C++ -> Code Generation -> Runtime Library and setting it to Multithreaded DLL (/MD).
Under General I set the configuration type to be a static library (.lib).

visual c++, LINK : fatal error LNK1104: cannot open file

I'm new C++, I have a dll file called DiceInvaders.dll, in my project, I need to use this library, I'm using visual c++ 2010, I set the Linker Input as DiceInvaders.lib and DiceInvaders.dll, I also copied this dll file to my porject directory, I always got error in this line of code:
m_lib = LoadLibrary("DiceInvaders.dll");
assert(m_lib);
The error is assertion failure. How should I solve this? Thank you in advance.
First you cannot pass the DLL to the linker like you are, it is not a file type that the linker recognizes and cannot be linked that way. When you create the Diceinvaters.dll file the linker will create an import library with the same filename and the extension .lib. It appears this is already being done. That is the library file you should pass to the linker when building any application that uses it.
Second, the Diceinvaders.dll file must be accessible in the DLL search path. This varies slightly depending on which version of Windows you are using but is generally something like the following
The directory the program was loaded from.
The current working directory.
The System directory.
The Windows directory.
The directories that are listed in the PATH environment variable.
Placing the DLL in your project directory is not going to be enough. Instead you should place it in the same directory as the EXE file(s) that have a dependency on it.

error LNK2005: _DllMain#12 already defined in MSVCRT.lib

I am getting this linker error.
mfcs80.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRT.lib(dllmain.obj)
Please tell me the correct way of eliminating this bug. I read solution on microsoft support site about this bug but it didnt helped much.
I am using VS 2005 with Platform SDK
I had the same error message, but none of the answers here solved it for me.
So if you Encounter that Problem when creating a DLL Project that uses MFC, it can be resolved by entering the following line:
extern "C" { int _afxForceUSRDLL; }
to the cpp file where DllMain is defined. Then your own DllMain implementation is used, rather than the one from dllmain.obj.
When we try to use MFC library, we surely will include afx.h directly
or indirectly, then MFC(afx.h) tell the linker to find the symbol of
__afxForceUSRDLL and put that object which contains __afxForceUSRDLL into the program, so linker searches and puts dllmodule.obj into our
program, because __afxForceUSRDLL is defined in dllmodule.cpp.
That’s the common scenario. When we want to use our own DllMain in a
mfc dll project, linker complains that there are two DllMain, one in
our code, one in Dllmodule.obj.
So we need to tell the linker to add our dllmain.obj for
__afxForceUSRDLL. So we need to define __afxForceUSRDLL in our own cpp file where our own DllMain is defined, then the linker will ignore
mfc’s dllmodule.obj and see only one DllMain and never complains.
Source: http://social.msdn.microsoft.com/Forums/en-US/0d78aa6b-1e87-4c01-a4a7-691335b7351a/how-to-build-mfc-application-dll-in-visual-c-2010
If you read the linker error thoroughly, and apply some knowledge, you may get there yourself:
The linker links a number of compiled objects and libraries together to get a binary.
Each object/library describes
what symbols it expects to be present in other objects
what symbols it defines
If two objects define the same symbol, you get exactly this linker error. In your case, both mfcs80.lib and MSVCRT.lib define the _DllMain#12 symbol.
Getting rid of the error:
find out which of both libraries you actually need
find out how to tell the linker not to use the other one (using e.g. the tip from James Hopkin)
If you're defining your own DllMain, in your project settings you need to set 'Use of MFC' in the 'Configuration Properties/General' to 'Use Standard Windows Libraries'.
You should do a clean rebuild after changing it.
In my project I was able to solve this problem by adding mfcs80.lib and msvcrt.lib as additional dependencies in the project settings. The 'additional dependencies' can be found under Linker -> Input.
In the debug configuration that would have to be mfcs80d.lib and msvcrtd.lib respectively.
By the way, I am working with Visual Studio 2010, so in my case the MFC lib is called mfc100.lib.
I am not sure why this worked. It is not necessary to add these lib files as additional dependencies because I already set 'Use of MFC' to 'Use MFC in a shared dll'. I guess that by specifying these libraries as additional dependencies they are linked in a different order.
This solution is more or less the same as the one suggested on the Microsoft site: http://support.microsoft.com/kb/148652, except I did not need to type anything in the 'Ignore specific default libraries' box.
For me the direct cause was indeed a missing _afxForceUSRDLL symbol reference, but the indirect cause was a missing _USRDLL macro definition. It is defined by default by the VC wizard, but occasionally devs erase it erroneously.
Here it is in more words.
MSDN knowledge base ID Q148652.
http://support.microsoft.com/kb/148652
Cause:
Visual C++ compiles the source files in alphabetical order, and passes the compiled object files to the linker in alphabetical order.
If the linker processes DLLDATAX.OBJ first, the source code references DllMain, which the linker loads from MSVCRTD.LIB(dllmain.obj).
The linker then processes an object file compiled from a C++ file that contains #include "stdafx.h", which references the symbol
__afxForceUSRDLL, which the linker loads from MFC42D.LIB(dllmodul.obj). This object module also contains an implementation for DllMain,
causing the conflict.
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and the solution was add mfcs110d.lib to Additional Dependencies
For all those who are experiencing this error in ATL projects (mostly when trying to add MFC support), here's the solution I found after days of frustration!
First of all, this link was more helpful to me than all the others. It pointed me into the right direction. The problem occurs, if the "generated files" (containing the proxy and stub code, just as the type guids) for some reason have been removed and readded to the project. This causes Visual Studio to add them in the wrong order!
Usually you first come up with the "ATL requires C++ compilation" error, but you may have fixed this by turning out the Yc/Yu (precompiled headers) setting for that file.
What you should do next is unloading your project and edit it. Search for the item groups that define the build and include order (ClCompile and ClInclude). Check their order and settings.
The compiles should appear in this order:
dllmain.cpp (with CompileAsManaged set to false and PrecompiledHeader left empty).
Library source (MyLib.cpp, containing DllCanUnloadNow and so on)
Proxy/Stub code (MyLib_i.c; with same settings as dllmain.cpp)
stdafx.cpp (with PrecompiledHeader set to Create)
All the other library source files (your actual libraries content)
xdlldata.c (with the same settings as dllmain.cpp)
The includes should then be ordered like this:
dllmain.h
MyLib_i.h
Resource.h
stdafx.h
targetver.h
... (actual library headers)
xdlldata.h
Fixing the build order fixed my project and I was able to create a new clean build.
I have personally got rid of this error this way: right-clicked project in the Solution Explorer, selected Properties from pop-up menu, clicked Linker tab and added mfcs71ud.lib into Additional Dependencies. If you're using Visual Studio 2005, it should be "80" instead of "71" and so on.
In my case I had a problem with the preprocessor directives.
For some reason _USRDLL was defined, when it should not have been.
To check this, go to the menu Project , select Project Properties , then select the snippet Configuration Properties --> Preprocessor .
The preprocessor directives will be found there.
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional Dependancies field in the Project Properties -> Linker Tab -> Input of Visual Studio to fix the issue.
Just #undef the _USRDLL before including afx.h, or even better, edit your project configuration and remove the macro.
This is the usual configuration for a MFC extension DLL: Build Settings for an MFC DLL
Make sure you include "Stdafx.h" at the top of each .cpp file. I was getting the exact same error and had a single .cpp file that did not include this header at all. Adding the #include solved the problem.
I found solution Here
Visual Studio 2010 library linking order
this is: /FORCE:MULTIPLE
in linker options
I had to mix ATL and MFC together , to use
[module(name = "mymodule")]; construction in MFC application together with "__hook" keyword
I found this which helped me:
http://support.microsoft.com/kb/148652
Basically the linker order was incorrect. the CRT libs were getting linked before the MFC libs. Turns out, the MFC libs had to get linked FIRST, and then the CRT libs could be linked.
Yucko Microsoft!!
There is a common theme running through some of the answers here.
Avishek Bose:-
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional
Dependancies field in the Project Properties -> Linker Tab -> Input of
Visual Studio to fix the issue.
vmb100:-
I am working with Visual Studio 2010, so in my case the MFC lib is
called mfc100.lib.
joseAndresGomezTovar:-
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and
the solution was add mfcs110d.lib to Additional Dependencies
So the general case seems to be to first find the name of the library to add ...
and then to add it ....
Note that there seem to be some prerequisites and/or alternative solutions.
This can also occur if your solution has multiple projects that export the same symbols. For example if you have sub-project that builds foo.dll with a foo.def file that exports DoFoo and a sub-project for bar.dll with a bar.def file that exports DoFoo, a collision will occur and this is the error you will see when you link.