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  ("Magnus Hagander" <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Hannes Eder
Дата:
Сообщение: minor compiler warning in libpg/fe-secure.c on win32 (msvc)
Следующее
От: Decibel!
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix free space map to correctly track the total amount of FSM