Re: Latest ecpg patch broke MSVC build

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(at)12(dot)
>>
>
> 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(at)12
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "DllMain(at)12"
is :- "DllMain(at)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(at)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(at)12

as with libecpg

C:\Hannes\pgsql\Debug\libecpg>dumpbin /symbols misc.obj | grep Main
05E 000007B0 SECT5 notype () External | _DllMain(at)12

Am I missing something?

-Hannes