Magnus Hagander schrieb:
>>> Since this is an actual API library, perhaps a proper fix is to create a
>>> .def file listing the exports in it, the same way we do for libpq? And then
>>> we could (should!) also filter the exports the same ways as we do for libpq
>>> these days.
>>>
>>> (see the exports.txt file in libpq)
>>>
>>> I'll try to find time to look forther at this meanwhile, but if someone can
>>> confirm that donig an explicit export list is a good way to go, I can
>>> confirm that donig that fixes the build problem :-)
>>>
>>> //Magnus
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 6: explain analyze is your friend
>>>
>>>
>> According to:
>>
>> Module-Definition (.def) File EXPORT
>> http://msdn2.microsoft.com/en-us/library/ms856515.aspx
>>
>> whitespace is required between the name and the ordinal in a
>> .def-file, hence in the .def-file DllMain @12 should be used
>> instead of DllMain@12.
>>
>
> you're reading the problem wrong. The 12 is not the ordinal, it's a part of the decorated name.
>
>
> /Magnus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
but, we are compiling C so the names shouldn't be decorated.
undecorating yields the same name:
c:\hannes\>undname DllMain@12
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "DllMain@12"
is :- "DllMain@12"
compiling a little test program:
cat >dllmain.c <<EOF
#include <windows.h>
BOOL WINAPI
DllMain(HANDLE module, DWORD reason, LPVOID reserved)
{ return TRUE;
}
EOF
yields the same exported symbol
C:\Hannes>cl /c dllmain.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Hannes>dumpbin /symbols dllmain.obj
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file dllmain.obj
File Type: COFF OBJECT
COFF SYMBOL TABLE
[snip]
008 00000000 SECT3 notype () External | _DllMain@12
[snip]
When creating a new dll with VC 6.0, same here
C:\Hannes\testdll\Debug>dumpbin /symbols testdll.obj | grep Main
01B 00000000 SECT6 notype () External | _DllMain@12
as with libecpg
C:\Hannes\pgsql\Debug\libecpg>dumpbin /symbols misc.obj | grep Main
05E 000007B0 SECT5 notype () External | _DllMain@12
Am I missing something?
-Hannes
