gnu-misc-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MingW/Windows: Building g++ import lib for existing DLL


From: Alf P. Steinbach
Subject: MingW/Windows: Building g++ import lib for existing DLL
Date: Thu, 05 Feb 2009 09:24:21 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0

Hi.

[I don't know whether this, MinGW g++ tool usage, is on-topic here. I've failed to find a more relevant group. *MULTI-POST*: posted yesterday to gnu.gcc.help.]


I'm trying to build an import library for the Windows GDI+ API (Windows' basic modern graphics API), because it isn't supported by MinGW 3.4.5.

I know that this "should" be possible since MinGW has bundled import libraries for other Windows APIs, e.g. import libraries for [user32.dll] etc.

I've generated a module definition file that goes like this:

<code filename="gdiplus.dll.def">
EXPORTS
    GdipAddPathArc@28 = GdipAddPathArc
    GdipAddPathArcI@28 = GdipAddPathArcI
    GdipAddPathBezier@36 = GdipAddPathBezier
    GdipAddPathBezierI@36 = GdipAddPathBezierI
    GdipAddPathBeziers@12 = GdipAddPathBeziers
...
</code>

The ornamented names on the left are the ones that g++ wants; the plain ones on the right are those exported by [gdiplus.dll]. Microsoft's documentation (always unreliable) states that they should be in opposite order and so I've tried also that. I don't use ordinal numbers because I have the impression that MinGW tools don't support identifying DLL routines via ordinal numbers, only via names, but just to have tried everything I tried also that.

I use the module definition file like this, via MinGW tools 'objdump' and 'dlltool' (sorry about any added line-breaks in news article), where 'gen_deffile' is a program that generates the file shown above:

<commands>
objdump -p "%windir%\SYSTEM32\gdiplus.dll" | find "Gdip" | gen_deffile > gdiplus.dll.def
dlltool --def gdiplus.dll.def --dllname gdiplus.dll --output-lib 
libgdiplus.dll.a
</commands>

This generates an import library that works on the g++ side of things, static linking OK, but when run the Windows loader looks for the ornamented names in the DLL, not the plain ones that the DLL exports, and coughs up an error message "not found" for one of these names.

What can I do instead?


TIA. for any help,

- Alf


reply via email to

[Prev in Thread] Current Thread [Next in Thread]