0

I'm working on a C++ project that generates several EXEs and several DLLs. For the sake of neatness, I'd like to have those DLLs generated in a Lib folder, so the built project would look like this:

MyProject
----myExe1.exe
----myExe2.exe
----Lib
    ----myLib1.dll
    ----myLib2.dll

I was able to successfully get the DLLs built into the Lib folder, and I was able to successfully link to the DLLs in their new location using -L..\bin\Lib in the linking command for the EXEs. However, when I go to actually run the EXEs, they complain that they can't find the DLLs in question.

From the research I've done, it looks like even though I can link to libraries in other folders, loading them still requires them to be in the same folder as the binaries.

GCC, linking libraries, not found? suggests that this is simply the way things are meant to be, but mentions "the system has to be able to find the dll; i.e. it has to be in the current working directory, in a directory that is in the path, or its directory has to be added to a special environment variable used for this thing". What "special environment variable" is being referenced (I'm assuming it's not %PATH% or the comment wouldn't have specifically mentioned the path earlier), and is there a way I can set it so my DLLs can be properly loaded?

Community
  • 1
  • 1
cf-
  • 8,598
  • 9
  • 36
  • 58
  • 2
    You should put the DLLs next to the executables. –  Nov 07 '13 at 21:25
  • 1
    Make sure the DLLs are somewhere in your PATH environment variable. http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.110).aspx That "special environment variable" is a unix thing and is mentioned because gcc works on unix too, but the name of the special environment variable depends on which unix. – Jerry Jeremiah Nov 07 '13 at 21:33
  • @faranwath I'm fairly sure I've seen other apps do this successfully. Or is this just not a workable/best-practice thing? – cf- Nov 07 '13 at 21:41
  • @computerfreaker Thing is, you cannot be sure your clients will have their PATH environment variable set to handle this. In order to make sure the DLLs can be loaded, it's better to bundle them along with your executable. I cannot speak for other ways of doing this; it ALWAYS works. –  Nov 07 '13 at 21:45
  • @faranwath Fair enough. Given the way this app can potentially be distributed, I think I can safely say some users will **not** have %PATH% set to handle this. So it appears bundling the DLLs next to the binaries is the only option left? – cf- Nov 07 '13 at 21:48

1 Answers1

3

Complete information about DLL search order is on MSDN site: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Short version: During DLL loading the OS searches it in the following order:

  1. The directory from which the application loaded.
  2. The system directory (i.e. C:\Windows\System32)
  3. The 16-bit system directory.
  4. The Windows directory (i.e. C:\Windows)
  5. The current directory.
  6. The directories that are listed in the PATH environment variable.

So if you want to separate your exe file from dll then you have to put the folder with the libraries into PATH. Another option is dynamic DLL loading using LoadLibraryEx http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179%28v=vs.85%29.aspx

Alan Milton
  • 374
  • 4
  • 13
  • Thanks. That pretty much seals it for me: I'll have to leave the DLLs next to my EXEs. – cf- Nov 07 '13 at 22:03
  • 1
    6. is pretty important: If you really must have your DLLs in a subfolder you can simply use a .bat/.sh file that adds your DLL-folder to the PATH and runs your program. – Wingblade Mar 19 '14 at 02:13