Skip site navigation (1) Skip section navigation (2)

Re: Latest ecpg patch broke MSVC build

From: Hannes Eder <Hannes(at)HannesEder(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: andrew(at)dunslane(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, meskes(at)postgresql(dot)org, itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Latest ecpg patch broke MSVC build
Date: 2007-10-03 07:35:51
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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
>> 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>

DllMain(HANDLE module, DWORD reason, LPVOID reserved)
    return TRUE;

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


008 00000000 SECT3  notype ()    External     | _DllMain(at)12

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?


In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2007-10-03 07:47:54
Subject: Re: Latest ecpg patch broke MSVC build
Previous:From: Magnus HaganderDate: 2007-10-03 06:05:55
Subject: Re: Latest ecpg patch broke MSVC build

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group