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.140.240.193 with SMTP id l184mr7733915qhc.4.1449662533431; Wed, 09 Dec 2015 04:02:13 -0800 (PST) X-Received: by 10.182.44.169 with SMTP id f9mr73951obm.16.1449662533388; Wed, 09 Dec 2015 04:02:13 -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!f78no7387783qge.1!news-out.google.com!l1ni1418igd.0!nntp.google.com!mv3no13766984igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 9 Dec 2015 04:02:13 -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: Subject: Re: Using Gnat.Sockets in a Windows DLL From: ahlan@marriott.org Injection-Date: Wed, 09 Dec 2015 12:02:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:28732 Date: 2015-12-09T04:02:13-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 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?