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

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

[John Smith]

I've recently come across this example on rosettacode:
http://rosettacode.org/wiki/Call_a_function_in_a_shared_library#Ada

I have a project that's building a DLL.  There is a neighboring project file that builds an executable and needs to make use of the DLL.  Is it possible to include the DLL in the application through the 2nd project file?  Or would I need to do this through the code in the application explicitly (because it's a dynamically loaded library)?

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

[John Smith]

One more library related question.  I'm trying to execute the following:

$ gnatmake -L../../../interfaces foo_main.adb libInterfaceLib.a

libInterfaceLib.a is located in the interfaces directory above.  It's a static library.  How can I include it at the command line?

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

[Dmitry A. Kazakov]

On 02/10/2017 01:51, John Smith wrote:
> One more library related question.  I'm trying to execute the following:
> 
> $ gnatmake -L../../../interfaces foo_main.adb libInterfaceLib.a
> 
> libInterfaceLib.a is located in the interfaces directory above. It's
> a  static library. How can I include it at the command line?

Use project files.

Otherwise it is the -largs switch that passes options to the linker.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dmitry A. Kazakov]

On 01/10/2017 23:06, John Smith wrote:
> I've recently come across this example on rosettacode:
> http://rosettacode.org/wiki/Call_a_function_in_a_shared_library#Ada
> 
> I have a project that's building a DLL. There is a neighboring
> project file that builds an executable and needs to make use of the
> DLL. Is it possible to include the DLL in the application through the
> 2nd project file?

DLL is not included, it is loaded/linked/mapped to.

[ In order to include DLL you must extract object files from there, if 
that works, then put them into a static library and use that instead. ]

In the scenario when the DLL is to be linked to at build time and loaded 
automatically at the application start, you create two library project 
files. One is used to build the library itself. Another is to use the 
library in another project. See GNAT project files.

Essential for "build" project is

    for Library_Interface use (<units-list>);

which determines which Ada units get exported out of the library.

For the "use" project it is

    for Externally_Built use "true";

telling that the library is already built.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Monday, October 2, 2017 at 3:15:49 AM UTC-4, Dmitry A. Kazakov wrote:
> On 02/10/2017 01:51, John Smith wrote:
> > One more library related question.  I'm trying to execute the following:
> > 
> > $ gnatmake -L../../../interfaces foo_main.adb libInterfaceLib.a
> > 
> > libInterfaceLib.a is located in the interfaces directory above. It's
> > a  static library. How can I include it at the command line?
> 
> Use project files.
> 
> Otherwise it is the -largs switch that passes options to the linker.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Hi, thanks for writing back.

I'm able to use a project file, but it seems a little bit excessive in an instance when I have a small utility.

This is what I tried again:
gnatmake -L../../../bin/debug main_static.adb -largs libInterfaceLib.a

And this is what I got:
gnatmake : gnatmake: "debug" not found
At line:1 char:1
+ gnatmake -L../../../bin/debug .\main_static.adb -largs libsimpleLibs. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gnatmake: "debug" not found:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

I'm doing this in windows.

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

[Dmitry A. Kazakov]

On 02/10/2017 13:12, John Smith wrote:

> I'm able to use a project file, but it seems a little bit excessive
> in  an instance when I have a small utility.

That's the easiest way. Project manager knows a lot about the underlying 
OS and how to use libraries there.

> This is what I tried again:
> gnatmake -L../../../bin/debug main_static.adb -largs libInterfaceLib.a

    gnatmake main_static.adb -largs -L../../../bin/debug -lInterfaceLib

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

Hi Dmitry,

This is what I'm getting:

> gnatmake main_static.adb -largs -L../../../bin/debug -lsimpleLibs
gnatmake : gcc -c -I.\ -I- .\main_static.adb
At line:1 char:1
+ gnatmake .\main_static.adb -largs -L../../../bin/debug -lsimpleLibs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gcc -c -I.\ -I- .\main_static.adb:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
main_static.adb:9:06: file "geometry_shapes.ads" not found
main_static.adb:10:06: file "calc_time.ads" not found
gnatmake: ".\main_static.adb" compilation error

:-/

This is in Windows.

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

[Dmitry A. Kazakov]

On 2017-10-03 00:44, John Smith wrote:
> Hi Dmitry,
> 
> This is what I'm getting:
> 
>> gnatmake main_static.adb -largs -L../../../bin/debug -lsimpleLibs
> gnatmake : gcc -c -I.\ -I- .\main_static.adb
> At line:1 char:1
> + gnatmake .\main_static.adb -largs -L../../../bin/debug -lsimpleLibs
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      + CategoryInfo          : NotSpecified: (gcc -c -I.\ -I- .\main_static.adb:String) [], RemoteException
>      + FullyQualifiedErrorId : NativeCommandError
>   
> main_static.adb:9:06: file "geometry_shapes.ads" not found
> main_static.adb:10:06: file "calc_time.ads" not found
> gnatmake: ".\main_static.adb" compilation error

That is not link error. You have the problem that some Ada source files 
*.ads are not reachable [which is the reason why project files are used].

The gnatmake switch -I<dir> is to specify a directory to look for 
additional Ada sources.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Tuesday, October 3, 2017 at 3:14:25 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-03 00:44, John Smith wrote:
> > Hi Dmitry,
> > 
> > This is what I'm getting:
> > 
> >> gnatmake main_static.adb -largs -L../../../bin/debug -lsimpleLibs
> > gnatmake : gcc -c -I.\ -I- .\main_static.adb
> > At line:1 char:1
> > + gnatmake .\main_static.adb -largs -L../../../bin/debug -lsimpleLibs
> > + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >      + CategoryInfo          : NotSpecified: (gcc -c -I.\ -I- .\main_static.adb:String) [], RemoteException
> >      + FullyQualifiedErrorId : NativeCommandError
> >   
> > main_static.adb:9:06: file "geometry_shapes.ads" not found
> > main_static.adb:10:06: file "calc_time.ads" not found
> > gnatmake: ".\main_static.adb" compilation error
> 
> That is not link error. You have the problem that some Ada source files 
> *.ads are not reachable [which is the reason why project files are used].
> 
> The gnatmake switch -I<dir> is to specify a directory to look for 
> additional Ada sources.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Ok, I feel kind of stupid.  I've tried to include the source like so, but keep getting the above error that I posted earlier:

gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug -lsimpleLibs

The result:

gnatmake : gcc -c main_static.adb
At line:1 char:1
+ gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gcc -c main_static.adb:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
main_static.adb:9:06: file "geometry_shapes.ads" not found
main_static.adb:10:06: file "calc_time.ads" not found
gnatmake: "main_static.adb" compilation error

No clue what the problem is now.  I've included the source where the *.ads file are located.

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

[Dmitry A. Kazakov]

On 2017-10-03 13:32, John Smith wrote:

> I've tried to include the source like so, but keep getting the above error that I posted earlier:
> 
> gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug -lsimpleLibs

The switch -I is not for linker, it is for compiler!

    gnatmake -I../../../src
             main_static.adb
             -largs -L../../../bin/debug -lsimpleLibs

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Dennis Lee Bieber]

On Tue, 3 Oct 2017 04:32:20 -0700 (PDT), John Smith
<yoursurrogategod@gmail.com> declaimed the following:

>
>Ok, I feel kind of stupid.  I've tried to include the source like so, but keep getting the above error that I posted earlier:
>
>gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug -lsimpleLibs
>

https://gcc.gnu.org/onlinedocs/gnat_ugn/Mode-Switches-for-gnatmake.html
"""
The effect of a mode switch is to cause all subsequent switches up to the
end of the switch list, or up to the next mode switch, to be interpreted as
switches to be passed on to the designated component of GNAT. 
"""

	The .ads files are needed by the compiler stage (and maybe the
binder?), not the linker, so their location needs to be specified before
the use of "-largs".
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

[John Smith]

On Tuesday, October 3, 2017 at 9:43:52 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-03 13:32, John Smith wrote:
> 
> > I've tried to include the source like so, but keep getting the above error that I posted earlier:
> > 
> > gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug -lsimpleLibs
> 
> The switch -I is not for linker, it is for compiler!
> 
>     gnatmake -I../../../src
>              main_static.adb
>              -largs -L../../../bin/debug -lsimpleLibs
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Hi again,

I did what you suggested and this is the error that I'm getting now:

gnatmake : gnatmake: could not find the main ALI file
At line:1 char:1
+ gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gnatmake: could...e main ALI file:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Why do the ALI files matter?  Aren't the definitions in the *.ads files?  Are the *.o file needed as well?

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

[John Smith]

On Tuesday, October 3, 2017 at 7:28:06 PM UTC-4, John Smith wrote:
> On Tuesday, October 3, 2017 at 9:43:52 AM UTC-4, Dmitry A. Kazakov wrote:
> > On 2017-10-03 13:32, John Smith wrote:
> > 
> > > I've tried to include the source like so, but keep getting the above error that I posted earlier:
> > > 
> > > gnatmake main_static.adb -largs -aI../../../src -L../../../bin/debug -lsimpleLibs
> > 
> > The switch -I is not for linker, it is for compiler!
> > 
> >     gnatmake -I../../../src
> >              main_static.adb
> >              -largs -L../../../bin/debug -lsimpleLibs
> > 
> > -- 
> > Regards,
> > Dmitry A. Kazakov
> > http://www.dmitry-kazakov.de
> 
> Hi again,
> 
> I did what you suggested and this is the error that I'm getting now:
> 
> gnatmake : gnatmake: could not find the main ALI file
> At line:1 char:1
> + gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : NotSpecified: (gnatmake: could...e main ALI file:String) [], RemoteException
>     + FullyQualifiedErrorId : NativeCommandError
> 
> Why do the ALI files matter?  Aren't the definitions in the *.ads files?  Are the *.o file needed as well?

Also, I've tried this and got the following result:

$ gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs -L../../../bin/debug -lsimpleLibs
gnatmake : gnatmake: missing source directory name
At line:1 char:1
+ gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gnatmake: missing source directory name:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Now the complaint is about the lack of a source file... *sigh*

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

[Dmitry A. Kazakov]

On 04/10/2017 04:10, John Smith wrote:

>> I did what you suggested and this is the error that I'm getting now:
>>
>> gnatmake : gnatmake: could not find the main ALI file
>> At line:1 char:1
>> + gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...
>> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>      + CategoryInfo          : NotSpecified: (gnatmake: could...e main ALI file:String) [], RemoteException
>>      + FullyQualifiedErrorId : NativeCommandError
>>
>> Why do the ALI files matter?  Aren't the definitions in the *.ads files?  Are the *.o file needed as well?

It is GNAT-specific. You can think about it this way. *.ali to *.ads is 
what *.o to *.adb is. But *.o can be put into a library while *.ali 
cannot because GNU linker does not know Ada.

> Also, I've tried this and got the following result:
> 
> $ gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs -L../../../bin/debug -lsimpleLibs
> gnatmake : gnatmake: missing source directory name
> At line:1 char:1
> + gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs - ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      + CategoryInfo          : NotSpecified: (gnatmake: missing source directory name:String) [], RemoteException
>      + FullyQualifiedErrorId : NativeCommandError
> 
> Now the complaint is about the lack of a source file... *sigh*

    gnatmake -l../../../src
             -aL../../../ali/debug
             main_static.adb
             -largs -L../../../bin/debug -lsimpleLibs

That is why project files to be used. Otherwise you must fine tune 
gnatmake options. That's the price to pay.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Wednesday, October 4, 2017 at 4:10:36 AM UTC-4, Dmitry A. Kazakov wrote:
> On 04/10/2017 04:10, John Smith wrote:
> 
> >> I did what you suggested and this is the error that I'm getting now:
> >>
> >> gnatmake : gnatmake: could not find the main ALI file
> >> At line:1 char:1
> >> + gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...
> >> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>      + CategoryInfo          : NotSpecified: (gnatmake: could...e main ALI file:String) [], RemoteException
> >>      + FullyQualifiedErrorId : NativeCommandError
> >>
> >> Why do the ALI files matter?  Aren't the definitions in the *.ads files?  Are the *.o file needed as well?
> 
> It is GNAT-specific. You can think about it this way. *.ali to *.ads is 
> what *.o to *.adb is. But *.o can be put into a library while *.ali 
> cannot because GNU linker does not know Ada.
> 
> > Also, I've tried this and got the following result:
> > 
> > $ gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs -L../../../bin/debug -lsimpleLibs
> > gnatmake : gnatmake: missing source directory name
> > At line:1 char:1
> > + gnatmake -l../../../src main_static.adb -A../../../ali/debug -largs - ...
> > + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >      + CategoryInfo          : NotSpecified: (gnatmake: missing source directory name:String) [], RemoteException
> >      + FullyQualifiedErrorId : NativeCommandError
> > 
> > Now the complaint is about the lack of a source file... *sigh*
> 
>     gnatmake -l../../../src
>              -aL../../../ali/debug
>              main_static.adb
>              -largs -L../../../bin/debug -lsimpleLibs
> 
> That is why project files to be used. Otherwise you must fine tune 
> gnatmake options. That's the price to pay.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I see what you mean.  This is the latest that I tried (what you suggested) and the result that I received:

> gnatmake -l../../../src -aL../../../ali/debug main_static.adb -largs -L../../../bin/debug -lsimpleLibs
gnatmake : gnatmake: missing library directory name
At line:1 char:1
+ gnatmake -l../../../src -aL../../../ali/debug main_static.adb -largs  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gnatmake: missing library directory name:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

One problem that I had when dealing with project files is that I'm including the library's project file in the compilation process.  This makes it really easy to include the library in my application.  However, I'm not sure what to do when I don't have the said project file.

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

[Dmitry A. Kazakov]

On 04/10/2017 13:23, John Smith wrote:

> However, I'm not sure what to do when I don't have the said project file.

You create it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Wednesday, October 4, 2017 at 7:48:57 AM UTC-4, Dmitry A. Kazakov wrote:
> On 04/10/2017 13:23, John Smith wrote:
> 
> > However, I'm not sure what to do when I don't have the said project file.
> 
> You create it.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I mean the project file for the library that I'm trying to use.  Would you create that as well?

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

[Dmitry A. Kazakov]

On 04/10/2017 13:54, John Smith wrote:

> I mean the project file for the library that I'm trying to use.  Would you create that as well?

Yes. It is basically same as the build-project with

    for Externally_Built use "true";

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Wednesday, October 4, 2017 at 7:59:29 AM UTC-4, Dmitry A. Kazakov wrote:
> On 04/10/2017 13:54, John Smith wrote:
> 
> > I mean the project file for the library that I'm trying to use.  Would you create that as well?
> 
> Yes. It is basically same as the build-project with
> 
>     for Externally_Built use "true";
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Going back to my earlier error.  Why does the compiler now complain about the lack of library directory name?  This is specified using the -l flag.

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

[Dmitry A. Kazakov]

On 04/10/2017 14:04, John Smith wrote:

> Going back to my earlier error. Why does the compiler now complain
> about the lack of library directory name? This is specified using the -l
> flag.

No idea, maybe you need -aO<dir> or something else. All depends on how 
crazy your directory tree is.

Then without a project file gnatmake has no idea if sources are from 
another project like library rather than from the project at hand.

gnatmake guesses that from files set read-only. I don't remember which, 
probably *.ali files from the library must be read-only.

P.S. Use gnatmake -v for verbosity.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Wright]

John Smith <yoursurrogategod@gmail.com> writes:

> + gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...

That should be -I (capital letter i) not -1 (digit one).

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

[John Smith]

On Wednesday, October 4, 2017 at 11:03:32 AM UTC-4, Simon Wright wrote:
> John Smith <you.......gmail.com> writes:
> 
> > + gnatmake -l../../../src .\main_static.adb -largs -L../../../bin/debug ...
> 
> That should be -I (capital letter i) not -1 (digit one).

Worse yet, I had a lower-case letter "L".  I corrected it based on your suggestion and included -v as Dmitry suggested and this is what I'm seeing:

> gnatmake -v -I../../../src main_static.adb -largs -L../../../bin/debug -lsimpleLibs -A..\..\..\ali\debug
gnatmake : gnatmake: missing source directory name
At line:1 char:1
+ gnatmake -v -I../../../src main_static.adb -largs -L../../../bin/debu ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (gnatmake: missing source directory name:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError


Basically, this is my directory structure:

+---ali
|   +---debug
|   \---release
+---bin
|   +---debug
|   \---release
+---main
|   +---static
|       +---executable
|       \---project
+---obj
|   +---debug
|   \---release
\---src

bin has the library files *.a and *.dll

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

[John Smith]

Screw it.  I just made a secondary project file to wrap around the static library that I don't have the source code for... It "feels" like a dirty little solution, it works.

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

[John Smith]

On Thursday, October 5, 2017 at 7:55:57 PM UTC-4, John Smith wrote:
> Screw it.  I just made a secondary project file to wrap around the static library that I don't have the source code for... It "feels" like a dirty little solution, it works.

Ok, another problem.  I have this project file that is responsible to act as an in-between the *.a file for when I don't necessarily have the source code:

project Static_Project is
  for Externally_Built use "true";
  for Source_Files use ();
  for Library_Dir use "bin/debug";
  for Library_Name use "simpleLibs";
  for Library_Kind use "static";
end Static_Project;


The project file that's supposed to use them is this:

with "..\..\..\static_project";

project Main_Static is
  for Source_Dirs use (".");
  for Object_Dir use ".";
  for Main use ("main_static.adb");

  package Builder is
  end Builder;

  package Compiler is
    for Switches("Ada") use ("-g", "-gnatwa");
  end Compiler;

  package Binder is
  end Binder;

  package Linker is
  end Linker;
end Main_Static;


So, I compile stuff and I get an error message saying that there are missing *.ads files... but aren't I supposed to not have them in the first place?

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

[Dmitry A. Kazakov]

On 2017-10-06 04:21, John Smith wrote:

> Ok, another problem. I have this project file that is responsible to
> act as an in-between the *.a file for when I don't necessarily have the
> source code:

It must have source code of the library interface, obviously...

[...]

> So, I compile stuff and I get an error message saying that there are
> missing *.ads files... but aren't I supposed to not have them in the
> first place?

If you reference a package P doing "with P", how are you supposed to not 
have "p.ads"?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Friday, October 6, 2017 at 2:46:58 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-06 04:21, John Smith wrote:
> 
> > Ok, another problem. I have this project file that is responsible to
> > act as an in-between the *.a file for when I don't necessarily have the
> > source code:
> 
> It must have source code of the library interface, obviously...
> 
> [...]
> 
> > So, I compile stuff and I get an error message saying that there are
> > missing *.ads files... but aren't I supposed to not have them in the
> > first place?
> 
> If you reference a package P doing "with P", how are you supposed to not 
> have "p.ads"?
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Good point.  I did reference it now in the static_project.gpr.  Now it's complaining about not knowing which language it's dealing with.

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

[Dmitry A. Kazakov]

On 2017-10-06 13:30, John Smith wrote:

> Good point. I did reference it now in the static_project.gpr. Now
> it's  complaining about not knowing which language it's dealing with.

Check GNAT installation, gprconfig must list Ada compiler.

Library project should at least have:

library project ... is
    for Source_Dirs use (...);
    for Library_Kind use ...;
    for Library_Name use ...;
    for Library_Dir use ...;
    for Library_ALI_Dir use ...;
    for Externally_Built use "true";
end ...;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>    for Library_ALI_Dir use ...;

I've never used this; the ALIs are normally found in the library
directory (with the .a's).

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

[Dmitry A. Kazakov]

On 2017-10-06 20:57, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>     for Library_ALI_Dir use ...;
> 
> I've never used this; the ALIs are normally found in the library
> directory (with the .a's).

Both Debian and Fedora Ada policies require them different, e.g. in a 
subdirectory ./<library-name>/. Maybe in order not to clutter the the 
lib directory. GNAT under Windows does same. Otherwise, yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Friday, October 6, 2017 at 9:26:39 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-06 13:30, John Smith wrote:
> 
> > Good point. I did reference it now in the static_project.gpr. Now
> > it's  complaining about not knowing which language it's dealing with.
> 
> Check GNAT installation, gprconfig must list Ada compiler.
> 
> Library project should at least have:
> 
> library project ... is
>     for Source_Dirs use (...);
>     for Library_Kind use ...;
>     for Library_Name use ...;
>     for Library_Dir use ...;
>     for Library_ALI_Dir use ...;
>     for Externally_Built use "true";
> end ...;
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

It does:

> gprconfig
--------------------------------------------------
gprconfig has found the following compilers on your PATH.
Only those matching the target and the selected compilers are displayed.
   1. GNAT for Ada in c:\gnat\2016\bin\ version 2016 (default runtime)
   2. GNAT for Ada in c:\gnat\2016\bin\ version 2016 (sjlj runtime)
   3. GNAT for Ada in c:\gnat\2015\bin\ version 2015 (default runtime)
   4. GNAT for Ada in c:\gnat\2015\bin\ version 2015 (sjlj runtime)
   5. GCC-ASM for Asm in c:\gnat\2016\bin\ version 4.9.4
   6. GCC-ASM for Asm in c:\gnat\2016\bin\ version 4.9.4
   7. GCC-ASM for Asm in c:\gnat\2015\bin\ version 4.9.3
   8. GCC-ASM for Asm in c:\gnat\2015\bin\ version 4.9.3
   9. GCC-ASM for Asm2 in c:\gnat\2016\bin\ version 4.9.4
  10. GCC-ASM for Asm2 in c:\gnat\2016\bin\ version 4.9.4
  11. GCC-ASM for Asm2 in c:\gnat\2015\bin\ version 4.9.3
  12. GCC-ASM for Asm2 in c:\gnat\2015\bin\ version 4.9.3
  13. GCC-ASM for Asm_Cpp in c:\gnat\2016\bin\ version 4.9.4
  14. GCC-ASM for Asm_Cpp in c:\gnat\2016\bin\ version 4.9.4
  15. GCC-ASM for Asm_Cpp in c:\gnat\2015\bin\ version 4.9.3
  16. GCC-ASM for Asm_Cpp in c:\gnat\2015\bin\ version 4.9.3
  17. GCC for C in c:\gnat\2016\bin\ version 4.9.4
  18. GCC for C in c:\gnat\2016\bin\ version 4.9.4
  19. GCC for C in c:\gnat\2015\bin\ version 4.9.3
  20. GCC for C in c:\gnat\2015\bin\ version 4.9.3
  21. G++ for C++ in c:\gnat\2016\bin\ version 4.9.4
  22. G++ for C++ in c:\gnat\2015\bin\ version 4.9.3
  23. WINDRES for WinRes in c:\gnat\2016\bin\ version 2.24.51.20140908
  24. WINDRES for WinRes in c:\gnat\2015\bin\ version 2.24.51.20140908

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

[John Smith]

On Friday, October 6, 2017 at 9:26:39 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-06 13:30, John Smith wrote:
> 
> > Good point. I did reference it now in the static_project.gpr. Now
> > it's  complaining about not knowing which language it's dealing with.
> 
> Check GNAT installation, gprconfig must list Ada compiler.
> 
> Library project should at least have:
> 
> library project ... is
>     for Source_Dirs use (...);
>     for Library_Kind use ...;
>     for Library_Name use ...;
>     for Library_Dir use ...;
>     for Library_ALI_Dir use ...;
>     for Externally_Built use "true";
> end ...;
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

It seems like something is missing.  It's as if I explicitly need to state that the code is Ada.

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

[Dmitry A. Kazakov]

On 2017-10-07 05:57, John Smith wrote:

> It seems like something is missing. It's as if I explicitly need to
> state that the code is Ada.

    for Languages use ("Ada");

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2017-10-07 05:57, John Smith wrote:
>
>> It seems like something is missing. It's as if I explicitly need to
>> state that the code is Ada.
>
>    for Languages use ("Ada");

Yes, but isn't that effectively the default? I created a project with a
src/ containing just a Fortran file, and gprbuild said

   $ gprbuild
   using project file check.gpr
   check.gpr:1:09: warning: there are no Ada sources in this project
   gprbuild: no sources to compile

Put an Ada source in there,

   $ gprbuild
   using project file check.gpr
   Compile
      [Ada]          a.adb

Set 'for Languages use ("fortran");', rm *.o, then

   $ gprbuild
   using project file check.gpr
   Compile
      [fortran]      foo.f

Amusingly, the text inside the square brackets is that in the 'for
Languages' setting: I can get

   Compile
      [FoRtRaN]      foo.f

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

[John Smith]

On Saturday, October 7, 2017 at 4:25:50 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-07 05:57, John Smith wrote:
> 
> > It seems like something is missing. It's as if I explicitly need to
> > state that the code is Ada.
> 
>     for Languages use ("Ada");
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I did what you recommended, same error.  I'll upload the source in a zip file in a link.  I'm genuinely confused as heck over this.

https://www.expirebox.com/download/87152aad9e98a9011b37c7acac006e43.html

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

[Dmitry A. Kazakov]

On 2017-10-07 14:57, John Smith wrote:

> I did what you recommended, same error. I'll upload the source in a
> zip file in a link. I'm genuinely confused as heck over this.
> 
> https://www.expirebox.com/download/87152aad9e98a9011b37c7acac006e43.html

In "use_project.gpr"

   for Source_Files use ("src");

must have been:

   for Source_Dirs use ("src");

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Saturday, October 7, 2017 at 9:19:31 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2017-10-07 14:57, John Smith wrote:
> 
> > I did what you recommended, same error. I'll upload the source in a
> > zip file in a link. I'm genuinely confused as heck over this.
> > 
> > https://www.expirebox.com/download/87152aad9e98a9011b37c7acac006e43.html
> 
> In "use_project.gpr"
> 
>    for Source_Files use ("src");
> 
> must have been:
> 
>    for Source_Dirs use ("src");
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Ai!  What a stupid mistake!  Thanks for pointing it out!

If something takes me more than 3 days to do... it's usually just a few characters that are messing me up...

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

[John Smith]

Dmitry, this is odd.  I had everything building perfectly.  Now, when I try to have my DLL loaded, it gives me an error saying that it doesn't see it.

This is my project:
https://www.expirebox.com/download/924f4dddeaea12b473dff551f6741431.html

lib_build.gpr is used to build the code and use_project.gpr is in the middle to make it possible to find/build the application that uses that library (static and shared libraries.)

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

[Dmitry A. Kazakov]

On 10/10/2017 05:39, John Smith wrote:

> Now, when I try to have my DLL loaded, it gives me an error saying
> that it doesn't see it.
Check the OS rules about loader search path.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Tuesday, October 10, 2017 at 9:15:13 AM UTC-4, Dmitry A. Kazakov wrote:
> On 10/10/2017 05:39, John Smith wrote:
> 
> > Now, when I try to have my DLL loaded, it gives me an error saying
> > that it doesn't see it.
> Check the OS rules about loader search path.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

I'm assuming that it has something to do with gnatls (sorry, I'm not sure how this works on Windows.)  This did work shortly after I got the static libraries to work (they still do, the shared libraries do not work though) and I'm trying to figure out what I screwed up.

This is what I'm seeing when doing gnatls:

> gnatls -v

GNATLS GPL 2016 (20160515-49)
Copyright (C) 1997-2016, Free Software Foundation, Inc.

Source Search Path:
   <Current_Directory>
   C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adainclude


Object Search Path:
   <Current_Directory>
   C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adalib


Project Search Path:
   <Current_Directory>
   C:\GtkAda\lib\gnat
   C:\GNAT\2016\i686-pc-mingw32\lib\gnat
   C:\GNAT\2016\i686-pc-mingw32\share\gpr
   C:\GNAT\2016\share\gpr
   C:\GNAT\2016\lib\gnat

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

[Anh Vo]

On Tuesday, October 10, 2017 at 5:38:13 PM UTC-7, John Smith wrote:
> On Tuesday, October 10, 2017 at 9:15:13 AM UTC-4, Dmitry A. Kazakov wrote:
> > On 10/10/2017 05:39, John Smith wrote:
> > 
> > > Now, when I try to have my DLL loaded, it gives me an error saying
> > > that it doesn't see it.
> > Check the OS rules about loader search path.
> > 
> > -- 
> > Regards,
> > Dmitry A. Kazakov
> > http://www.dmitry-kazakov.de
> 
> I'm assuming that it has something to do with gnatls (sorry, I'm not sure how this works on Windows.)  This did work shortly after I got the static libraries to work (they still do, the shared libraries do not work though) and I'm trying to figure out what I screwed up.
> 
> This is what I'm seeing when doing gnatls:
> 
> > gnatls -v
> 
> GNATLS GPL 2016 (20160515-49)
> Copyright (C) 1997-2016, Free Software Foundation, Inc.
> 
> Source Search Path:
>    <Current_Directory>
>    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adainclude
> 
> 
> Object Search Path:
>    <Current_Directory>
>    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adalib
> 
> 
> Project Search Path:
>    <Current_Directory>
>    C:\GtkAda\lib\gnat
>    C:\GNAT\2016\i686-pc-mingw32\lib\gnat
>    C:\GNAT\2016\i686-pc-mingw32\share\gpr
>    C:\GNAT\2016\share\gpr
>    C:\GNAT\2016\lib\gnat

As a quick test, place all *.dll in the question at C:\Windows\System32

Anh Vo

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

[John Smith]

On Tuesday, October 10, 2017 at 9:18:12 PM UTC-4, Anh Vo wrote:
> On Tuesday, October 10, 2017 at 5:38:13 PM UTC-7, John Smith wrote:
> > On Tuesday, October 10, 2017 at 9:15:13 AM UTC-4, Dmitry A. Kazakov wrote:
> > > On 10/10/2017 05:39, John Smith wrote:
> > > 
> > > > Now, when I try to have my DLL loaded, it gives me an error saying
> > > > that it doesn't see it.
> > > Check the OS rules about loader search path.
> > > 
> > > -- 
> > > Regards,
> > > Dmitry A. Kazakov
> > > http://www.dmitry-kazakov.de
> > 
> > I'm assuming that it has something to do with gnatls (sorry, I'm not sure how this works on Windows.)  This did work shortly after I got the static libraries to work (they still do, the shared libraries do not work though) and I'm trying to figure out what I screwed up.
> > 
> > This is what I'm seeing when doing gnatls:
> > 
> > > gnatls -v
> > 
> > GNATLS GPL 2016 (20160515-49)
> > Copyright (C) 1997-2016, Free Software Foundation, Inc.
> > 
> > Source Search Path:
> >    <Current_Directory>
> >    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adainclude
> > 
> > 
> > Object Search Path:
> >    <Current_Directory>
> >    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adalib
> > 
> > 
> > Project Search Path:
> >    <Current_Directory>
> >    C:\GtkAda\lib\gnat
> >    C:\GNAT\2016\i686-pc-mingw32\lib\gnat
> >    C:\GNAT\2016\i686-pc-mingw32\share\gpr
> >    C:\GNAT\2016\share\gpr
> >    C:\GNAT\2016\lib\gnat
> 
> As a quick test, place all *.dll in the question at C:\Windows\System32
> 
> Anh Vo

But it's not searching for those DLLs in there.

I could put them into something like "C:\GNAT\2016\lib\gnat", but ultimately that's not what I want.

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

[Anh Vo]

On Tuesday, October 10, 2017 at 6:22:06 PM UTC-7, John Smith wrote:
> On Tuesday, October 10, 2017 at 9:18:12 PM UTC-4, Anh Vo wrote:
> > On Tuesday, October 10, 2017 at 5:38:13 PM UTC-7, John Smith wrote:
> > > On Tuesday, October 10, 2017 at 9:15:13 AM UTC-4, Dmitry A. Kazakov wrote:
> > > > On 10/10/2017 05:39, John Smith wrote:
> > > > 
> > > > > Now, when I try to have my DLL loaded, it gives me an error saying
> > > > > that it doesn't see it.
> > > > Check the OS rules about loader search path.
> > > > 
> > > > -- 
> > > > Regards,
> > > > Dmitry A. Kazakov
> > > > http://www.dmitry-kazakov.de
> > > 
> > > I'm assuming that it has something to do with gnatls (sorry, I'm not sure how this works on Windows.)  This did work shortly after I got the static libraries to work (they still do, the shared libraries do not work though) and I'm trying to figure out what I screwed up.
> > > 
> > > This is what I'm seeing when doing gnatls:
> > > 
> > > > gnatls -v
> > > 
> > > GNATLS GPL 2016 (20160515-49)
> > > Copyright (C) 1997-2016, Free Software Foundation, Inc.
> > > 
> > > Source Search Path:
> > >    <Current_Directory>
> > >    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adainclude
> > > 
> > > 
> > > Object Search Path:
> > >    <Current_Directory>
> > >    C:\GNAT\2016\lib\gcc\i686-pc-mingw32\4.9.4\adalib
> > > 
> > > 
> > > Project Search Path:
> > >    <Current_Directory>
> > >    C:\GtkAda\lib\gnat
> > >    C:\GNAT\2016\i686-pc-mingw32\lib\gnat
> > >    C:\GNAT\2016\i686-pc-mingw32\share\gpr
> > >    C:\GNAT\2016\share\gpr
> > >    C:\GNAT\2016\lib\gnat
> > 
> > As a quick test, place all *.dll in the question at C:\Windows\System32
> > 
> > Anh Vo
> 
> But it's not searching for those DLLs in there.
> 
> I could put them into something like "C:\GNAT\2016\lib\gnat", but ultimately that's not what I want.

If you decide to put them in GNAT, then put them in C:\GNAT\2016\bin.

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

[Dmitry A. Kazakov]

On 11/10/2017 02:38, John Smith wrote:

> I'm assuming that it has something to do with gnatls (sorry, I'm not
> sure how this works on Windows.) This did work shortly after I got the
> static libraries to work (they still do, the shared libraries do not
> work though) and I'm trying to figure out what I screwed up.

Static libraries are linked statically. DLLs are linked at run-time by 
the system loader. There are rules where the loader looks for the DLLs.

Under Windows they are:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

P.S. The simplest way is to put the executable in the same directory 
with the DLL.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

On Wednesday, October 11, 2017 at 3:08:16 AM UTC-4, Dmitry A. Kazakov wrote:
> On 11/10/2017 02:38, John Smith wrote:
> 
> > I'm assuming that it has something to do with gnatls (sorry, I'm not
> > sure how this works on Windows.) This did work shortly after I got the
> > static libraries to work (they still do, the shared libraries do not
> > work though) and I'm trying to figure out what I screwed up.
> 
> Static libraries are linked statically. DLLs are linked at run-time by 
> the system loader. There are rules where the loader looks for the DLLs.
> 
> Under Windows they are:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
> 
> P.S. The simplest way is to put the executable in the same directory 
> with the DLL.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

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.

This compiles the *.exe:

with "../../../use_project.gpr";

project Main_Dynamic is
  for Source_Dirs use (".");
  for Object_Dir use ".";
  for Main use ("main_dynamic.adb");

  package Builder is
  end Builder;

  package Compiler is
    for Switches("Ada") use ("-g", "-gnatwa");
  end Compiler;

  package Binder is
  end Binder;

  package Linker is
  end Linker;
end Main_Dynamic;




And this is what points to the compiled DLL (but doesn't compile it):

library project Use_Project is
  for Externally_Built use "true";
  for Source_Dirs use ("src");
  for Library_Dir use "bin/debug";
  for Library_Name use "simpleLibs";
  for Library_Kind use "dynamic";
  for Library_ALI_Dir use "ali/debug";
end Use_Project;

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

[Dmitry A. Kazakov]

On 11/10/2017 14:09, John Smith wrote:

> I've had the binary that uses the *.DLL having it include the library
> via the *.gpr file and that used to work.
It has nothing to do with project files, except that you can tell where 
to put the DLL and EXE once they are built.

Write an installation script with Inno setup or whatever else tool for 
deployment. Or move files manually to their ultimate destinations. It is 
not compiler's business.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[John Smith]

What you described in this post, is what I'm trying to accomplish for my DLL.

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

[John Smith]

DLL is not included, it is loaded/linked/mapped to. 

[ In order to include DLL you must extract object files from there, if 
that works, then put them into a static library and use that instead. ] 

In the scenario when the DLL is to be linked to at build time and loaded 
automatically at the application start, you create two library project 
files. One is used to build the library itself. Another is to use the 
library in another project. See GNAT project files. 

Essential for "build" project is 

    for Library_Interface use (<units-list>); 

which determines which Ada units get exported out of the library. 

For the "use" project it is 

    for Externally_Built use "true"; 

telling that the library is already built.


===================================


In the above post.

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

[Randy Brukardt]

"John Smith" <yoursurrogategod@gmail.com> wrote in message 
news:18781206-12b4-4da8-ac8c-96d4151fa6b3@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.

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

[John Smith]

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.)

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

[John Smith]

No ideas what could be missing?  Here is the zipped project again:

https://www.expirebox.com/download/010fe50325012304e2a47e6917b214da.html

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

[Robert Eachus]

On Wednesday, October 11, 2017 at 6:57:35 PM UTC-4, John Smith wrote:
> 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.
> 

What happens if you put the .dll in C:\Windows\SysWOW64 That would imply that you are creating (or looking for) a 64-bit DLL.