From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.137.130 with SMTP id s124mr377789itd.30.1507762653821; Wed, 11 Oct 2017 15:57:33 -0700 (PDT) X-Received: by 10.157.14.201 with SMTP id 67mr84982otj.4.1507762653788; Wed, 11 Oct 2017 15:57:33 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!k70no863318itk.0!news-out.google.com!194ni1027itf.0!nntp.google.com!l196no859227itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 Oct 2017 15:57:33 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:18f:900:f900:453d:87a5:de7c:1786; posting-account=AvekzAoAAABj-TclKcOWQmXwA49MFPGX NNTP-Posting-Host: 2601:18f:900:f900:453d:87a5:de7c:1786 References: <9885a3fd-8ffa-4076-ba1f-db2f8035e0dc@googlegroups.com> <5984e47c-cfe5-4d22-9907-f113f24647b9@googlegroups.com> <2bc424a1-3559-42bb-9f40-22763c21e7f2@googlegroups.com> <761a5a41-04de-4f48-aac2-f5fe167dabd5@googlegroups.com> <41f9bb00-4fa3-472e-98e4-d32e5ae4e2d6@googlegroups.com> <2f235de2-5969-4cf8-ada6-c0d886f0f9ac@googlegroups.com> <2d6225df-f847-4324-a7f0-e4544d0b5b44@googlegroups.com> <18781206-12b4-4da8-ac8c-96d4151fa6b3@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <307494b9-c79d-4e8a-887c-3a588374b082@googlegroups.com> Subject: Re: The best possible way to call a function in a shared library From: John Smith Injection-Date: Wed, 11 Oct 2017 22:57:33 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:48433 Date: 2017-10-11T15:57:33-07:00 List-Id: On Wednesday, October 11, 2017 at 6:25:25 PM UTC-4, Randy Brukardt wrote: > "John Smith" wrote in message=20 > 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. >=20 > No. Loading (seeparate) DLLs is handled by Windows, and you have to follo= w=20 > the Window's rules for that. The compiler has nothing to do with it, and= =20 > thus project files have nothing to do with it. This works much like the= =20 > running of any executable -- that's a Windows function, not a=20 > compiler/linker function. >=20 > Several people have suggested that you place the .DLL (temporarily) in a= =20 > place where Windows will always look for it (like System32) to find out= =20 > whether or not it is a loading problem or some compilation problem (where= =20 > further playing with project files will be profitable). I'd suggest doing= =20 > that and (if necessary) providing the results here. >=20 > Randy. Putting the DLL file into the same directory as the executable will cause t= he binary to run as it should. Putting the same DLL into C:\Windows\System32 gives me the exception that t= he DLL in question cannot be found. Over the weekend, I somehow managed to keep the binary in its bin/debug dir= ectory and compile my executable and run it flawlessly. I know that this w= as not a static library because I checked that there were no *.a files befo= re I compiled the executable (also, the compiled program was quite small in= size when compared to the executable created using a static library.) I w= ish I had somehow saved the state of these files somehow just to be sure th= at if I screw them up in the future I can go back to that working state (bu= t I did not and this was my fault.)