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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e29fa9bf33a54d0b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!inka.de!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: michael bode Newsgroups: comp.lang.ada Subject: Re: MinGW GNAT 3.4.4 linking problem Date: 14 Oct 2005 14:56:33 +0200 Organization: 1&1 Internet AG Message-ID: References: NNTP-Posting-Host: p54afbb64.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: online.de 1129294595 8939 84.175.187.100 (14 Oct 2005 12:56:35 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Fri, 14 Oct 2005 12:56:35 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Xref: g2news1.google.com comp.lang.ada:5644 Date: 2005-10-14T14:56:33+02:00 List-Id: michael bode writes: > The library uses StdCall conventions and I have the .dll and .lib > compiled with Microsoft VC98. Interestingly everything work fine with > GNAT 3.15p. When I change the PATH to point to C:\MINGW\bin instead > C:\GNAT\bin -> 'undefined symbol'. Problem solved. The library exports names of the form '_function@N' which is as I've learned typical for a MSVC .dll created with __declspec(dllexport). Somehow gnat 3.4.4 expects names of the form 'function@N' without leading underscore. Proper solution: use dll-tools and DEF files to mangle the names into 'function@N' form. Simple solution: pragma Import (StdCall, function, "_function") GNAT 3.15p is quite happy with pragma Import (StdCall, function, "function"). Is that a well known change?