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 Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Meskes <meskes(at)postgresql(dot)org>, ITAGAKI Takahiro <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-02 22:58:29
Message-ID: 4702CD15.4060404@HannesEder.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander schrieb:
> On Sun, Sep 30, 2007 at 11:30:35PM -0400, Andrew Dunstan wrote:
>   
>> Tom Lane wrote:
>>     
>>> This morning's ecpg patch certainly seems to have been snake-bit.
>>> Although the Windows gcc buildfarm members seem happy, the MSVC ones
>>> are all failing with
>>>
>>> Linking...
>>>           Creating library Release\libecpg\libecpg.lib and object 
>>>           Release\libecpg\libecpg.exp
>>>        libecpg.exp : error LNK2001: unresolved external symbol DllMain(at)12
>>>        .\Release\libecpg\libecpg.dll : fatal error LNK1120: 1 unresolved 
>>>        externals
>>>
>>> I see that DllMain() got added to misc.c, so it's not obvious what's
>>> wrong here.  Some adjustment needed in the MSVC build scripts maybe?
>>>
>>>
>>>  
>>>       
>> It is building with thread.c but it should not be unless I am misreading 
>>     
>
> It's been building with thread.c before this patch. And the problem doesn't
> go away if you ermove thread.c.
>
>
> The problem seems to be that it tries to export a decorated DllMain
> (DllMain(at)12) which is listed in the object file, but it's unable to export
> it. Will need to dig further.
>
> The reason it doesn't happen on mingw is likely the horrible kludge that is
> export-all-symbols-in-all-files that we've only partially been able to
> emulate.
>
> 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)

Therefor I think the fix should be addressed in tools/msvc/gendef.pl, 
see attached diff.

Anyway there is just a single occurence of an ordinal in the .def-files:

$ grep '@' `find -name "*.def"`
./libecpg/LIBECPG.def:  DllMain @12

The ordinal 12 seems to be the default for DllMain.

-Hannes


Attachment: gendef.pl-200710031.diff
Description: text/x-diff (403 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: Decibel!Date: 2007-10-03 00:17:39
Subject: Re: [HACKERS] Re: pgsql: Fix free space map to correctly track the total amount of FSM
Previous:From: Neil ConwayDate: 2007-10-02 22:18:00
Subject: Re: minor compiler warning in libpg/fe-secure.c on win32(msvc)

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