DLL cannot be found on another computer
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
Windows XP.
I created a DLL to be called from another program. They both are located in the same folder/directory. On the computer where I developed it, the DLL is found. But when I take the files to another computer, the program gets a DLL not found error. It is not a path issue, since I move the files together some place else, and the same error occurs.
I rebuilt the DLL on the other computer and it still has the same issue. So, I suspect it has to do with how the other program finds the DLL. But then I have the a DLL created with Watcom compiler, and it finds that one. I used to use Watcom, but I prefer Dev C++, and I do not want to return to Watcom or use Microsoft.
Please advice if you know of some DLL configuration which may be sensitive to the computer local environment.
I have been unable to find where one DLL knows where another DLL is located. The issue is that I downloaded Cairo compiled and also with development files from the GTK website, and it expects to find the DLL at program files common files gtk 2.0 bin.
> Question now is - how do I control where the DLL will go to find other DLLs.
> Is there some place in the documentation which discusses this very painful process?
It is not a Dev-C++ issue. It is the operating system that deals with DLL location. Windows will first look in the same folder that the .exe resides in, then it searches the folders specified by the PATH environment variable in the order listed. So if a matching DLL is found in the path before the one your application actually needs, you may link the wrong DLL..
The simplest (but possibly least efficient) solution is to always place your DLL with the application that uses it.
Shared application DLLs were a great idea in the days when hard drives were a few hundred megabytes and program's were typically much larger than teh documents/files they created. But I am willing to bet that the majority of most peoples drives is filled with pictures, videos and music, and the application files space is relatively small. Keeping a local copy of a DLL or statically linking libraries is often simpler and more robust. Leave shared DLLs for the OS API, where they are still essential IMO. As a user I prefer it when an application does not scatter its files all across my hard drive, and placing files in c:\windows\ is particularly annoying.
Clifford
> All I can say is that it did not look AT LINK TIME at the current directory.
DLLs are linked at runtime, not link time. If you are in fact talking about a build error, post the build log so we can see exactly what you are seeing rather than what you are attempting to describe.
> But when I take the files to another computer, the program gets a DLL not found error.
Which sounds like a run-time error, not a build error. Which 'program' are you talking about here? The linker or your own executable? I am now very confused; you seem to have changed the story.
A DLL is typically associated with an export library which is statically linked to your executable. This is found in the normal manner.You can do any of teh following:
1) Specify the path and file name to the .a file fully (there is a button on the project options dialog to do that)
2) Specify search paths with -L options (there is a box in teh project options directories dialog for adding these), then specifying the export library via -l options (in the project options linker options box).
Regarding documentation, be aware that Dev-C++ is not a compiler/linker, it is merely an IDE. If you want documentation for the toolchain, you have to look at the relevant GNU docs. In the case of the linker, it is documented at:http://sourceware.org/binutils/docs-2.17/ld/index.html
> It found GTK in the PATH variable and hard coded that as the RUN TIME (LOAD TIME for a DLL) place to look.
That sounds very unlikely! Unless the application is dynamically changing the search path at run-time.
> Once I removed GTK from PATH variable it no longer hard coded where to find the DLL
I suggest that in fact it just stopped finding the wrong DLL, since it will use the first one it comes across.
> I would have preferred to compile Cairo from source
You keep mentioning that like we are all aware of what it is. Cairo was the pre-release code name for Windows NT 4.0.
> but I was not having much success with that since the make files were so complex.
You might do better trying to build it under the MinGW MSYS shell which supports Linux build steps such as processing configure scripts and make files.
Clifford
I found the problem. There are nested dependencies in the DLL I developed. And it happened to find these libraries from another application I installed, which does not exist in the other computer. The tool to use to find DLL dependencies is http://www.dependencywalker.com/ .
Question now is - how do I control where the DLL will go to find other DLLs. I will either figure that out for myself in Dev C++ or someone from here can answer that.
Thank you.
Also, the GTK website gives a dll.a file and a .lib file. Which one should I be linking against?
Final solution was to notice that GTK was in the PATH variable. So, the Dev C++ Linker was somehow (I do not really understand) finding the DLLs it needs at run time there, and fixing that into the DLL it was linking. So I removed GTK from the PATH variable and rebooted and then recompiled my DLL. Now it will find the DLLs (cairo and the 2 others) in the same folder.
Is there some place in the documentation which discusses this very painful process?
A. Katz.
> Is there some place in the documentation which discusses this very painful process?
A more definitive answer to your request: http://msdn.microsoft.com/en-us/library/ms682586.aspx
You will note that there are a few additional places that Windows will look that I did not mention; but that is perhaps academic, because you should not place your application files in any of them if you want to keep on the right side of your users.
Also as you can see from where this documentation resides it is not a Dev-C++ issue.
Clifford
All I can say is that it did not look AT LINK TIME at the current directory. It found GTK in the PATH variable and hard coded that as the RUN TIME (LOAD TIME for a DLL) place to look. Once I removed GTK from PATH variable it no longer hard coded where to find the DLL at RUN TIME.
Since the DLLs in question were downloaded by me (binary as well as development) from GTK's website, I suspect that inside of the library is some sort of hard coded reference to where GTK would be installed. I would have preferred to compile Cairo from source, but I was not having much success with that since the make files were so complex.
Andy