Re: The best possible way to call a function in a shared library

[John Smith <yoursurrogategod@gmail.com>]

On Wednesday, October 11, 2017 at 6:25:25 PM UTC-4, Randy Brukardt wrote:
> "John Smith" <yours....@gmail.com> wrote in message 
> news:18781206-12b4-4d.......@googlegroups.com...
> ...
> > I've had the binary that uses the *.DLL having it include the
> > library via the *.gpr file and that used to work.  When it comes
> >to finding the DLL, that should be handled by the related GPRs.
> 
> No. Loading (seeparate) DLLs is handled by Windows, and you have to follow 
> the Window's rules for that. The compiler has nothing to do with it, and 
> thus project files have nothing to do with it. This works much like the 
> running of any executable -- that's a Windows function, not a 
> compiler/linker function.
> 
> Several people have suggested that you place the .DLL (temporarily) in a 
> place where Windows will always look for it (like System32) to find out 
> whether or not it is a loading problem or some compilation problem (where 
> further playing with project files will be profitable). I'd suggest doing 
> that and (if necessary) providing the results here.
> 
>                                      Randy.

Putting the DLL file into the same directory as the executable will cause the binary to run as it should.

Putting the same DLL into C:\Windows\System32 gives me the exception that the DLL in question cannot be found.

Over the weekend, I somehow managed to keep the binary in its bin/debug directory and compile my executable and run it flawlessly.  I know that this was not a static library because I checked that there were no *.a files before I compiled the executable (also, the compiled program was quite small in size when compared to the executable created using a static library.)  I wish I had somehow saved the state of these files somehow just to be sure that if I screw them up in the future I can go back to that working state (but I did not and this was my fault.)