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.129.132.136 with SMTP id u130mr9831329ywf.11.1461403474662; Sat, 23 Apr 2016 02:24:34 -0700 (PDT) X-Received: by 10.182.27.8 with SMTP id p8mr287753obg.19.1461403474502; Sat, 23 Apr 2016 02:24:34 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!10no5992265qgg.1!news-out.google.com!u9ni92igk.0!nntp.google.com!sq19no226237igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 23 Apr 2016 02:24:34 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:1205:c68c:9d90:5427:cb02:649d:b73c; posting-account=Pm0FhgoAAAAiPscNT3etSZ15tHNZGXm_ NNTP-Posting-Host: 2a02:1205:c68c:9d90:5427:cb02:649d:b73c References: <220ee60f-3290-43d7-a097-cf90380d8bae@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3fb08b80-80d3-46c6-b368-1620154373da@googlegroups.com> Subject: Re: Using Gnat.Sockets in a Windows DLL From: ahlan.marriott@gmail.com Injection-Date: Sat, 23 Apr 2016 09:24:34 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 6657 X-Received-Body-CRC: 2159047844 Xref: news.eternal-september.org comp.lang.ada:30255 Date: 2016-04-23T02:24:34-07:00 List-Id: 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