I have an executable which is linked to a DLL library. This DLL is in c:\windows\system32
If I put a second DLL in the same path of the executable, this DLL should be loaded instead of the c:\windows\system32
It is very strange because it works like this for some DLLs and not for other.
I tried to copy all dlls of c:\windows\system32 in my executable path and I see with IDA (module window) that some DLLs are loaded in the executable path and others are still loaded in c:\windows\system32
I have scanned all DLLs content, thinking the path was hard coded, but I just see strings with just dll name.
So my question is: What is the rule applied by windows in order to choose which dll to load if there is multiple versions (in executable path and in c:\windows\system32)
Thanks
Related
In Windows, an executable(.exe) which needs a shared library (.dll) can be run when the exe and dll files are in a same directory.
In Linux, even though the executable and the shared library(.so) are in the same directory, Linux always looks for it in the absolute directory where .so was first built, then fails to run the executable.
Setting LD_LIBRARY_PATH or RPATH environment variable before running the executable is a ad-hoc solution, but I want to do it without setting the environment variable, and make it behaves like Windows.
How can I do it? I added "-rpath=$ORIGIN" to CMakelists but it still fails.
For just experimenting, I made a simple program and another shared library and tried dlopen and it works as I wanted. However, I don't use dlopen for this case.
I found the solution: add rpath option to CMakelists.txt for the executable, not for the shared library.
I have a ..dll. My ..exe must include this dll file.
I have seen this link How to use external DLLs in CMake project, but this is correct for me.
How to add search dll path in cmake?
Compiler: Mingw GCC compiler
In make file I specified src directory location like below..
dirsrc = ./src
So here I mentioned current directory. The problem is the generated DLL having the Absolute path to the source directory. Is there any way to notify the compiler which should be relative.?
Because I am generating this DLL with Codecoverage information. If I moved my full project structure to somewhere means while simulating the DLL to target, at that time the DLL refers to the absolute path of the source directory.
I need the DLL with relative path to the source directory.? How do I write the make file with relative path to the source directory?
The real problem is,
I am doing code coverage analysis using gcov.
I followed following steps:
1.) I compiled my program with GNU CC options: `-fprofile-arcs -ftest-coverage'.
2.) I got 2 additional file with suffix *.bb and *.bbg in same directory
3.) Running the program will cause profile output to be generated.
For each source file compiled with -fprofile-arcs', an accompanying .da' file will be placed in the source directory. The name of the .da' file is stored as an *_absolute pathname_* in the resulting object file. This path name is derived from the source file name by substituting a .da' suffix.
The problem here is that I am compiling on one machine and running on a seperate machine. Each '.da' file has absoulte pathname in the resulting object file. So it does not find same path on another machine.
Is it possible to have fprofile-arcs and any other profiling-related options in GCC to have file names relative rather than absolute.
please let me asap.! thanks in advance.
IDE: VS2005
Say I am using Poco library and the executable needs below dlls. I have to put them in same directory where the executable is.
msjava.dll
msvcp80.dll
msvcr80.dll
PocoFoundation.dll
PocoNet.dll
Is there any way that can build a dll-free executable? Thanks.
They don't have to be in the same directory. They can be in another directory if your PATH variables includes the directory they are in.
It looks like the Poco libraries can be downloaded as source, so you should be able to build them as static libraries and make a stand alone executable.
Update
For the msvc DLL's, you can build against static libraries. Bring up the properties of your project, go to C/C++, Code Generation and modify "Runtime Library". Make sure to choose a library other then "Multi-threaded DLL" or "Multi-threaded Debug DLL." You will also want to make sure you do that for the Poco libraries as well.
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."