Using Gnat.Sockets in a Windows DLL

Using Gnat.Sockets in a Windows DLL

[ahlan]

We have windows programs and DLLs that use the Windows WinSock API directly.
In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
This is relatively trivial.
Or at least it is for programs.
When we try to convert our DLLs we run into a linker problem.
If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
See below.
I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
Except that the names are not quite right so I suspect that this is the root cause of the problem.
Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?

Best wishes,
Ahlan
-----------

gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
gprlib.exe Cal_Dll.lexch
gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
collect2.exe: error: ld returned 1 exit status
gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
gprbuild: could not build library for project cal_dll
[2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On Wed, 25 Nov 2015 23:56:55 -0800 (PST), ahlan@marriott.org wrote:

> We have windows programs and DLLs that use the Windows WinSock API directly.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds
> when we build our programs (its in Windows/System32)

Yes

> Except that the names are not quite right so I suspect that this is the
> root cause of the problem.

The names are right, WinSock2 has stdcall conventions and names.

> Has anyone any idea why a build of a DLL should behave differently to a
> build of a program with respect to name mangling?

It should not. You link to libws2_32.a import library, which comes with
GNAT distribution.

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

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Thursday, November 26, 2015 at 8:57:02 AM UTC+1, ah...@marriott.org wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

If I have a one line test program that merely initialises a socket, ie

  My_Socket : GNAT.Sockets.Socket_Type;
begin
  GNAT.Sockets.Create_Socket (My_Socket);

then we have no problems building an executable but if we try and use the same
lines in a DLL we fail to find the external references.
Even if I explicitly put "Pragma Linker_Options ("-lws2_32");
and place libws2_32.a in the Library_Dir Gnat still fails to satisfy the references.

I am at a loss as to what I might be doing wrong and what I could try next.
This should be easy to solve, it probably has nothing to do with Gnat Sockets
but more to do with building DLLs using a GPR file.

The following is our Gpr file
with "gtkada";
with "win32ada";

project Monitor is

   package Naming is
      for Casing use "mixedcase";
   end Naming;

   for Library_Name use "Monitor";
   for Shared_Library_Prefix use "";

   for Source_Dirs use ("w:\source\ada\interfaces\monitor",
                        "w:\source\ada\interfaces",
                        "w:\source\ada\shared",
                        "w:\source\ada\open\shared");

   for Library_Interface use ("Monitor_Interface");

   for Object_Dir use "objects";

   for Library_Options use ("-Lw:\product\windows", "resources.o");
   for Library_Dir use "w:\product\windows";
   for Library_Ali_Dir use "d:\binary\ada\interfaces\monitor";
   for Library_Kind use "dynamic";
   for Library_Standalone use "encapsulated";

   package Pretty_Printer is
      for Default_Switches ("ada") use ("-i2", "-M120", "-aL", "-A1", "-A4");
   end Pretty_Printer;

   package Builder is
      for Default_Switches ("ada") use ("-s", "-g");
   end Builder;

   package Compiler is
      for Default_Switches ("ada") use ("-O1", "-gnatQ", "-gnato", "-g", "-gnat12",
                                        "-gnatwcehijkmopruvz.c.n.p.t.w.x", "-gnatykmpM120");
   end Compiler;

   package Binder is
      for Default_Switches ("ada") use ("-E");
   end Binder;




We build are DLLs using Gprbuild.
I

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On Mon, 7 Dec 2015 23:43:18 -0800 (PST), ahlan@marriott.org wrote:

> If I have a one line test program that merely initialises a socket, ie
> 
>   My_Socket : GNAT.Sockets.Socket_Type;
> begin
>   GNAT.Sockets.Create_Socket (My_Socket);
> 
> then we have no problems building an executable but if we try and use the same
> lines in a DLL we fail to find the external references.
> Even if I explicitly put "Pragma Linker_Options ("-lws2_32");
> and place libws2_32.a in the Library_Dir Gnat still fails to satisfy the references.
> 
> I am at a loss as to what I might be doing wrong and what I could try next.
> This should be easy to solve, it probably has nothing to do with Gnat Sockets
> but more to do with building DLLs using a GPR file.
> 
> The following is our Gpr file
> with "gtkada";
> with "win32ada";
> 
> project Monitor is
> 
>    package Naming is
>       for Casing use "mixedcase";
>    end Naming;
> 
>    for Library_Name use "Monitor";
>    for Shared_Library_Prefix use "";
> 
>    for Source_Dirs use ("w:\source\ada\interfaces\monitor",
>                         "w:\source\ada\interfaces",
>                         "w:\source\ada\shared",
>                         "w:\source\ada\open\shared");
> 
>    for Library_Interface use ("Monitor_Interface");
> 
>    for Object_Dir use "objects";
> 
>    for Library_Options use ("-Lw:\product\windows", "resources.o");
>    for Library_Dir use "w:\product\windows";
>    for Library_Ali_Dir use "d:\binary\ada\interfaces\monitor";
>    for Library_Kind use "dynamic";
>    for Library_Standalone use "encapsulated";
> 
>    package Pretty_Printer is
>       for Default_Switches ("ada") use ("-i2", "-M120", "-aL", "-A1", "-A4");
>    end Pretty_Printer;
> 
>    package Builder is
>       for Default_Switches ("ada") use ("-s", "-g");
>    end Builder;
> 
>    package Compiler is
>       for Default_Switches ("ada") use ("-O1", "-gnatQ", "-gnato", "-g", "-gnat12",
>                                         "-gnatwcehijkmopruvz.c.n.p.t.w.x", "-gnatykmpM120");
>    end Compiler;
> 
>    package Binder is
>       for Default_Switches ("ada") use ("-E");
>    end Binder;

How about:

package Linker is
   for Linker_Options use ("-lws2_32");
end Linker;

P.S. You also can create projects for the external DLLs (like Windows DLL)
you wanted to use. E.g.

project w32n55 is
   for Externally_Built use "true";
   for Source_Files use ();
   for Library_Dir use "where the DLL resides";
   for Library_Name use "w32n55";
   for Library_Kind use "dynamic";
end w32n55;

Then you "with" this project in your project.

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

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Thursday, November 26, 2015 at 8:57:02 AM UTC+1, ah...@marriott.org wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

Dear Dmitry,
Adding
package Linker is
   for Linker_Options use ("-lws2_32");
end Linker; 
to my Gpr file made absolutely no difference.
Can you reproduce this problem on your system?
If so and if your solution works what version of Gnat are you using?
I am using GPL 2015

All you have to do is create a socket in an exist DLL product.
Ie a three line change.

To be honest I didn't expect your solution to work because surely this is equivalent to my adding pragma Linker_Options into the source, which, as I wrote did not help.

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On Tue, 8 Dec 2015 23:20:03 -0800 (PST), ahlan@marriott.org wrote:

> Can you reproduce this problem on your system?

Ah, I overlooked that you did this:

   for Library_Standalone use "encapsulated";

An encapsulated project cannot depend on any dynamic libraries.

Since WS2_32 is a DLL, you cannot use it and thus GNAT.Sockets as well
because Windows does not provide static versions of system libraries.

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

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Thursday, November 26, 2015 at 8:57:02 AM UTC+1, ah...@marriott.org wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

Dear Dmitry,
We have to set encapsulated otherwise GprBuild complains
shared library project "monitor" cannot import static library project "win32ada"
because we with Win32Ada in order that we can make calls to the Windows API
Does this mean that the solution is to write a Gnat_Sockets.gpr?
If so what would look like - or does it already exist?

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On Wed, 9 Dec 2015 04:02:13 -0800 (PST), ahlan@marriott.org wrote:

> We have to set encapsulated otherwise GprBuild complains
> shared library project "monitor" cannot import static library project "win32ada"

This is because you forgot to select the "relocatable" scenario for
win32ada. E.g. when using gprbuild:

   grpbuild -P... -XWIN32ADA_BUILD=relocatable

There is a static build of win32ada which is the default scenario.

 E.g.
----- test.gpr >>>>>>>>>>>
with "win32Ada.gpr";
library project Test is
   for Library_Name use "test";
   for Library_Kind use "dynamic";
   for Library_Dir  use "c:/temp";
   for Library_Interface use ("test"); 
   for Library_Standalone use "standard";
end Test;
----- test.gpr <<<<<<<<<<<

---- test.adb >>>>>>>>>>>
with GNAT.Sockets;  use GNAT.Sockets;
with Win32;         use Win32;
with Win32.WinBase; use Win32.WinBase;
with Win32.WinNT;   use Win32.WinNT;

function Test return String is
   Self : HANDLE;
begin
   Self := GetCurrentProcess; -- Windows API call
   return Host_Name; -- GNAT.Sockets call
end Test;
---- test.adb <<<<<<<<<<<

gprbuild -d -PC:\Temp\Z\test.gpr -XWIN32ADA_BUILD=relocatable
gcc -c test.adb
gprlib.exe test.lexch
gnatbind -n -o b__test.adb -Ltest -a C:\Temp\Z\test.ali
gcc.exe -c -x ada -gnatA -gnatws b__test.adb -o b__test.o ...
gcc.exe -shared -shared-libgcc -o C:\temp\libtest.dll ... C:\Temp\Z\test.o
...

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

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Thursday, November 26, 2015 at 8:57:02 AM UTC+1, ah...@marriott.org wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

Dear Dmitry,

We didn't forget, we want to use a static build so that our DLLs are self contained so that, with the exception of Window System DLLs, we don't have to distribute lots of DLLs. Eg Gnat runtime.

Is there a way that we can make encapsulated DLLs that use Gnat.sockets?
It should be possible because, at the end of the day, Gnat Sockets is using the same Windows API that Win32 uses.

MfG
Ahlan

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On Wed, 9 Dec 2015 07:06:37 -0800 (PST), ahlan@marriott.org wrote:

> Is there a way that we can make encapsulated DLLs that use Gnat.sockets?

You could copy GNAT.Sockets source files into your project and patch them a
bit.

> It should be possible because, at the end of the day, Gnat Sockets is
> using the same Windows API that Win32 uses.

Maybe yes, maybe no. There might be some initialization required and/or
conflicts when statically linked.

But if you are going to use Windows API, then your library would not be
portable. Thus there is not much sense to use GNAT.Sockets. The beauty of
GNAT.Sockets is that it is same under Windows, Linux, VxWorks.

Use Winsock2 straight away. There is no much difference to GNAT.Sockets
anyway (except for socket selector).

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

Re: Using Gnat.Sockets in a Windows DLL

[Simon Wright]

ahlan@marriott.org writes:

> We didn't forget, we want to use a static build so that our DLLs are
> self contained so that, with the exception of Window System DLLs, we
> don't have to distribute lots of DLLs. Eg Gnat runtime.
>
> Is there a way that we can make encapsulated DLLs that use Gnat.sockets?
> It should be possible because, at the end of the day, Gnat Sockets is
> using the same Windows API that Win32 uses.

Looking at the AdaCore documentation, it's far from clear what the use
case for 'encapsulated' is.

You said above that you were having trouble with a shared library
'monitor', I don't understand why you don't build the whole project with
static libraries?

(BTW, could you look at how you're posting? I see 64 lines quoting your
original post - not even the one you're replying to - before I get to
the new material)

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

Dear Dmitry,

We currently use Winsock2 but I would like to use Gnat Sockets so that our code can run on platforms other than Windows.
The DLL will be Windows only but it shares code that we use with executables that I would like to run on Linux and OSX. For this reason I would like this shared code to use Gnat Sockets.

Dear Simon,
The Monitor DLL is a deliverable that is used by non-Ada programs.
It uses code that is used by other projects that I would like to execute on platforms other than Windows
Hence the interest in using Gnat Sockets.
However we want the DLL to be self contained (other than for the Windows DLL that all Windows systems have) so that we don't have to ship Gnat DLLs etc along with our DLL.

Is this post better?

Best regards,
Ahlan

Re: Using Gnat.Sockets in a Windows DLL

[Simon Wright]

ahlan@marriott.org writes:

> Dear Simon,
> The Monitor DLL is a deliverable that is used by non-Ada programs.
> It uses code that is used by other projects that I would like to
> execute on platforms other than Windows
> Hence the interest in using Gnat Sockets.
> However we want the DLL to be self contained (other than for the
> Windows DLL that all Windows systems have) so that we don't have to
> ship Gnat DLLs etc along with our DLL.

I see, thanks for the clarification. I thought the suggestion might
help, clearly not! Sorry.

> Is this post better?

It has many fewer lines, but it's still a reply to your original post,
which means that I can't go to the post it's actually a reply to.

On the other hand, I think you may be using Google Groups?, and I see
that GG has no threading capability at all! (or perhaps it's very well
hidden).

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Saturday, December 12, 2015 at 1:47:58 PM UTC+1, Simon Wright wrote:
> ahlan@marriott.org writes:
> 
> > Dear Simon,
> > The Monitor DLL is a deliverable that is used by non-Ada programs.
> > It uses code that is used by other projects that I would like to
> > execute on platforms other than Windows
> > Hence the interest in using Gnat Sockets.
> > However we want the DLL to be self contained (other than for the
> > Windows DLL that all Windows systems have) so that we don't have to
> > ship Gnat DLLs etc along with our DLL.
> 
> I see, thanks for the clarification. I thought the suggestion might
> help, clearly not! Sorry.
> 
> > Is this post better?
> 
> It has many fewer lines, but it's still a reply to your original post,
> which means that I can't go to the post it's actually a reply to.
> 
> On the other hand, I think you may be using Google Groups?, and I see
> that GG has no threading capability at all! (or perhaps it's very well
> hidden).

Dear Simon,
Yes I am using Google groups using Safari as web browser - is there another way?
Regards,
Ahlan

Re: Using Gnat.Sockets in a Windows DLL

[Simon Wright]

On Saturday, 12 December 2015 19:44:07 UTC, ah...@marriott.org  wrote:
> On Saturday, December 12, 2015 at 1:47:58 PM UTC+1, Simon Wright wrote:
> > ahlan@marriott.org writes:

> > > Is this post better?
> > 
> > It has many fewer lines, but it's still a reply to your original post,
> > which means that I can't go to the post it's actually a reply to.
> > 
> > On the other hand, I think you may be using Google Groups?, and I see
> > that GG has no threading capability at all! (or perhaps it's very well
> > hidden).
> 
> Yes I am using Google groups using Safari as web browser - is there another way?

Same here, this time (normally I use Emacs Gnus).

This post of yours appeared as a follow-up to my post, which is the way it should be; I used the double-headed arrow at top right of your post to follow-up.

Re: Using Gnat.Sockets in a Windows DLL

[ahlan]

On Thursday, November 26, 2015 at 8:57:02 AM UTC+1, ah...@marriott.org wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s


To summarise: We want to build an encapsulated DLL so that we don't have to distribute the Ada Runtime etc. AdaCore define an encapsulated library as only depending on system libraries.
However I wonder what is meant by system libraries.
We can successfully link if we restrict ourselves coroutines defined in Win32
In our gpr we "with Win32ada;" and can link Winsock routines
however if we try to use Gnat.Sockets the link fails to find entry points such as gethostname@8
this entry point is defined in libws2_32.a but all our attempts to provide this static library seem to be ignored.
We have tried pragma linker_options and specifying the file using "for linker_Options use" in the project gpr.
I have even tried making a library project gpr file with the sole purpose of defining where libws2_32.a can be found.
I suspect therefore that encapsulated libraries somehow "know" what libraries are "system libraries" and ignores all attempts to include others.
Which therefore begs the question as to how I can add Ws2_32 to this list of known libraries.
Surely Ws2_32 is as much a system library as WinSock?
so why should encapsulated libraries be able to use Winsock and not Ws2_32?
Any ideas anyone?

Re: Using Gnat.Sockets in a Windows DLL

[Simon Wright]

ahlan@marriott.org writes:

> To summarise: We want to build an encapsulated DLL so that we don't
> have to distribute the Ada Runtime etc. AdaCore define an encapsulated
> library as only depending on system libraries.
> However I wonder what is meant by system libraries.

From the sources of GPRBUILD GPL 2015, at gprlib.adb:2213,

    Library_Options_Table.Append (Libgnat);

    --  ?? The proper implementation for the following code is to
    --  add only the libraries that libgnat is using. This information
    --  is not readily available but we should be able to compute
    --  this from the ALI files.

    declare
       I : constant Natural := Object_Files.Last;
    begin
       --  Then adds back all libraries already on the command-line
       --  after libgnat to fulfill dependencies on OS libraries
       --  that may be used by the GNAT runtime. These are libraries
       --  added with a pragma Linker_Options in sources.

Not much help, I konw.

Re: Using Gnat.Sockets in a Windows DLL

[ahlan.marriott]

On Thursday, 26 November 2015 08:57:02 UTC+1, ah...@marriott.org  wrote:
> We have windows programs and DLLs that use the Windows WinSock API directly.
> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> This is relatively trivial.
> Or at least it is for programs.
> When we try to convert our DLLs we run into a linker problem.
> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> See below.
> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> 
> Best wishes,
> Ahlan
> -----------
> 
> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> gprlib.exe Cal_Dll.lexch
> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> collect2.exe: error: ld returned 1 exit status
> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> gprbuild: could not build library for project cal_dll
> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s

Dear all,

It seems that this is an known problem.
At least to AdaCore.
They document it as KP-22-O331-001
The problem is fixed in GprBuild v2.2.2 that is part of Gnat Pro 7.3.2
Otherwise the workaround is not to produce an encapsulated DLL but to produce a standard DLL and link in the static version of the Gnat runtime using Library_options.
A standard DLL will link WS2_32 and linking in the static runtime will produce a standalone DLL.

MfG
Ahlan

Re: Using Gnat.Sockets in a Windows DLL

[Dmitry A. Kazakov]

On 2016-01-13 21:25, ahlan.marriott@gmail.com wrote:
> On Thursday, 26 November 2015 08:57:02 UTC+1, ah...@marriott.org  wrote:
>> We have windows programs and DLLs that use the Windows WinSock API directly.
>> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
>> This is relatively trivial.
>> Or at least it is for programs.
>> When we try to convert our DLLs we run into a linker problem.
>> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
>> See below.
>> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
>> Except that the names are not quite right so I suspect that this is the root cause of the problem.
>> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
>>
>> Best wishes,
>> Ahlan
>> -----------
>>
>> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
>> gprlib.exe Cal_Dll.lexch
>> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
>> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
>> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
>> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
>> collect2.exe: error: ld returned 1 exit status
>> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
>> gprbuild: could not build library for project cal_dll
>> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s
>
> Dear all,
>
> It seems that this is an known problem.
> At least to AdaCore.
> They document it as KP-22-O331-001
> The problem is fixed in GprBuild v2.2.2 that is part of Gnat Pro 7.3.2
> Otherwise the workaround is not to produce an encapsulated DLL but
> to  produce a standard DLL and link in the static version of the Gnat
> runtime using Library_options.
> A standard DLL will link WS2_32 and linking in the static runtime will produce a standalone DLL.

I built the latest grpbuild from Git sources (not easy under Windows). 
The problem with encapsulated library projects persists.

Presently I believe it is related to the order in which libraries 
wsock32 and ws2_32 appear in the linker's command like. From what I read 
researching the issue, for some mysterious reasons, -lws2_32 -lwsock32 
must appear *before* -shared -static-libgcc. So the linker line must 
look like:

gcc.exe -lws2_32 -lwsock32 -shared -static-libgcc -o W:\product...

There is "Leading_Library_Option" project attribute, but it is no help 
because it does not bring its content right after gcc.exe.

Any ideas how to do it otherwise?

For example, a very crude way would to write an application 
my_gcc_wrapper that calls gcc with -lws2_32 -lwsock32 preceding all 
other switches and replace

package Linker is
    for Driver ("Ada") use "my_gcc_wrapper.exe";
end Linker;

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

Re: Using Gnat.Sockets in a Windows DLL

[ahlan.marriott]

On Wednesday, 20 April 2016 19:11:09 UTC+2, Dmitry A. Kazakov  wrote:
> On 2016-01-13 21:25, ahlan.marriott@gmail.com wrote:
> > On Thursday, 26 November 2015 08:57:02 UTC+1, ah...@marriott.org  wrote:
> >> We have windows programs and DLLs that use the Windows WinSock API directly.
> >> In order to make this code target independent (at least for Linux & OSX) we thought we should convert the code to use Gnat.Sockets.
> >> This is relatively trivial.
> >> Or at least it is for programs.
> >> When we try to convert our DLLs we run into a linker problem.
> >> If all we do is a "with Gnat.Sockets" then using GprBuild produces lots of messages saying that various entry points could not be found.
> >> See below.
> >> I recognize many of them as being in WS2_32.dll - which GprBuild finds when we build our programs (its in Windows/System32)
> >> Except that the names are not quite right so I suspect that this is the root cause of the problem.
> >> Has anyone any idea why a build of a DLL should behave differently to a build of a program with respect to name mangling?
> >>
> >> Best wishes,
> >> Ahlan
> >> -----------
> >>
> >> gprbuild -d -PD:\Binary\Ada\tools\cal_dll\Cal_Dll.gpr -XWIN32ADA_BUILD=default -XLIBRARY_TYPE=static
> >> gprlib.exe Cal_Dll.lexch
> >> gnatbind -n -o b__Cal_Dll.adb -LCal_Dll -a -E D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.ali
> >> gcc.exe -c -x ada -gnatA -gnatws b__cal_dll.adb -o b__cal_dll.o ...
> >> gcc.exe -shared -static-libgcc -o W:\product\windows\Cal_Dll.dll D:\Binary\Ada\tools\cal_dll\objects\cal_dll_interface.o ...
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1b46): undefined reference to `gethostname@8'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x1c9c): undefined reference to `getpeername@12'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x2323): undefined reference to `getsockopt@20'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socket.o):g-socket.adb:(.text+0x3518): undefined reference to `getsockopt@20'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x1c): undefined reference to `WSASetLastError@4'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x246): undefined reference to `WSASetLastError@4'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(g-socthi.o):g-socthi.adb:(.text+0x27f): undefined reference to `WSASetLastError@4'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x109): undefined reference to `_imp__getservbyname@8'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x159): undefined reference to `_imp__getservbyport@8'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x2a4): undefined reference to `__WSAFDIsSet@8'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x34c): undefined reference to `_imp__ioctlsocket@12'
> >> C:\gnatpro\7.3.1\lib\gcc\i686-pc-mingw32\4.9.3\/adalib/libgnat.a(socket.o):socket.c:(.text+0x3b4): undefined reference to `_imp__WSAStringToAddressA@20'
> >> collect2.exe: error: ld returned 1 exit status
> >> gprlib: c:\gnatpro\7.3.1\bin\gcc execution error
> >> gprbuild: could not build library for project cal_dll
> >> [2015-11-26 08:36:34] process exited with status 4, 100% (36/36), elapsed time: 01.67s
> >
> > Dear all,
> >
> > It seems that this is an known problem.
> > At least to AdaCore.
> > They document it as KP-22-O331-001
> > The problem is fixed in GprBuild v2.2.2 that is part of Gnat Pro 7.3.2
> > Otherwise the workaround is not to produce an encapsulated DLL but
> > to  produce a standard DLL and link in the static version of the Gnat
> > runtime using Library_options.
> > A standard DLL will link WS2_32 and linking in the static runtime will produce a standalone DLL.
> 
> I built the latest grpbuild from Git sources (not easy under Windows). 
> The problem with encapsulated library projects persists.
> 
> Presently I believe it is related to the order in which libraries 
> wsock32 and ws2_32 appear in the linker's command like. From what I read 
> researching the issue, for some mysterious reasons, -lws2_32 -lwsock32 
> must appear *before* -shared -static-libgcc. So the linker line must 
> look like:
> 
> gcc.exe -lws2_32 -lwsock32 -shared -static-libgcc -o W:\product...
> 
> There is "Leading_Library_Option" project attribute, but it is no help 
> because it does not bring its content right after gcc.exe.
> 
> Any ideas how to do it otherwise?
> 
> For example, a very crude way would to write an application 
> my_gcc_wrapper that calls gcc with -lws2_32 -lwsock32 preceding all 
> other switches and replace
> 
> package Linker is
>     for Driver ("Ada") use "my_gcc_wrapper.exe";
> end Linker;
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry,
This does indeed solve the problem.
However the problem is not in Gprbuild.exe but in libexec/gprbuild/gprlib.exe
Have you tried building that from the latest git sources?

MfG
Ahlan