Re: Latest ecpg patch broke MSVC build
От | Hannes Eder |
---|---|
Тема | Re: Latest ecpg patch broke MSVC build |
Дата | |
Msg-id | 4702CD15.4060404@HannesEder.net обсуждение исходный текст |
Ответ на | Re: Latest ecpg patch broke MSVC build (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Latest ecpg patch broke MSVC build
|
Список | 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@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 > > ---------------------------(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@12. 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 *** ../pgsql-cvshead/src/tools/msvc/gendef.pl Thu May 3 16:04:03 2007 --- src/tools/msvc/gendef.pl Wed Oct 3 00:53:23 2007 *************** *** 38,43 **** --- 38,46 ---- next if $pieces[6] =~ /^__NULL_IMPORT/; next if $pieces[6] =~ /^\?\?_C/; + # whitespace required between name and ordinal + $pieces[6] =~ s/@/ @/; + push @def, $pieces[6]; } close(F);
В списке pgsql-hackers по дате отправления: