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@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@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
