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 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.129.130.135 with SMTP id s129mr849349ywf.20.1449673598005; Wed, 09 Dec 2015 07:06:38 -0800 (PST) X-Received: by 10.182.241.195 with SMTP id wk3mr89326obc.8.1449673597970; Wed, 09 Dec 2015 07:06:37 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!b51no7413640qgf.0!news-out.google.com!l1ni1574igd.0!nntp.google.com!mv3no10816262igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 9 Dec 2015 07:06:37 -0800 (PST) In-Reply-To: <220ee60f-3290-43d7-a097-cf90380d8bae@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:120b:7f9:e740:f806:212b:2dfc:b2eb; posting-account=DQbqYQoAAACn8hHn2LmG2aF7Mhbxl_Lf NNTP-Posting-Host: 2a02:120b:7f9:e740:f806:212b:2dfc:b2eb References: <220ee60f-3290-43d7-a097-cf90380d8bae@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <10b1b56a-1dc6-4bc0-aea7-80b29882dccb@googlegroups.com> Subject: Re: Using Gnat.Sockets in a Windows DLL From: ahlan@marriott.org Injection-Date: Wed, 09 Dec 2015 15:06:37 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:28739 Date: 2015-12-09T07:06:37-08:00 List-Id: 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