Re: Latest ecpg patch broke MSVC build

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