Re: Mentioning CPU for Windows build in docs

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Mentioning CPU for Windows build in docs
Date: 2014-06-03 08:04:11
Message-ID: CAB7nPqRzRaUtY5peiS4mSuhK_Wu6=BJP83AJ1jwa-JaK8WP2Uw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

On Tue, Jun 3, 2014 at 3:37 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 06/02/2014 09:26 PM, Heikki Linnakangas wrote:
>>
>> On 06/02/2014 07:00 PM, Hiroshi Inoue wrote:
>>>
>>> (2014/06/02 20:54), Heikki Linnakangas wrote:
>>>>
>>>> On 06/02/2014 02:35 PM, Inoue, Hiroshi wrote:
>>>>>
>>>>> Official Windows build no longer uses nmake.
>>>>> The binaries are built using MSBuild.
>>>>> Please look at readme_winbuild.txt or winbuild/readme.txt.
>>>>
>>>>
>>>> Huh? Really?
>>>>
>>>> Why did we switch? What's the advantage of MSBuild over nmake?
>>>
>>>
>>> For example, MSBuild can switch the environment (Platform,
>>> VisualStudioVersion or platformToolset) easily. In fact
>>> BuildAll.ps1(bat) builds both 32bit and 64bit drivers.
>>> Or MSBuild can detect the changes of related files (e.g.
>>> header files).
>>>
>>> IMHO nmake is needed only for vc9 or before.
>>
>>
>> Well that makes one thing clear then: nobody cares about win32.mak
>> anymore. win64.mak can be used to build both 32-bit and 64-bit binaries,
>> and since the official binaries are built with the MSBuild method,
>> keeping the old flags & other configuration you got with win32.mak is
>> not important anymore. I'll go remove it.
>
>
> Oh, hang on. There's a file called buildx86.ps1 in the top directory, which
> calls "nmake /f win32.mak ...". So that's another PowerShell script, but it
> doesn't use MSBuild; it uses nmake.
>
> My guess: you created buildx86.ps1 and buildx64.ps1 first. Later, you
> created buildAll.ps1, and made completely independent of the old makefiles,
> but never got around to changing buildx86.ps1 and buildx64.ps1 to use the
> new build method.
>
> May I remove buildx86.ps1 and buildx64.ps1? I don't think we need yet
> another way to build on Windows..
When building with this new infrastructure, I am seeing a couple of
failures with MSDTC:
1) If nmake is 6.0 (?), MSDTC=yes build does not work:
pgenlist.def : error LNK2001: unresolved external symbol DtcOnDisconnect
pgenlist.def : error LNK2001: unresolved external symbol EnlistInDtc
pgenlist.def : error LNK2001: unresolved external symbol IsolateDtcConn
2) When specifying MSDTC=no with Visual 10 there are similar errors:
link.exe @C:\Users\mpaquier\AppData\Local\Temp\nm27A2.tmp
LINK : fatal error LNK1181: cannot open input file '.\x64\pgenlist.lib'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\Bin\amd64\link.exe"' : return code '0x49d'

I saw it working in case 2) with MSDTC=yes though.
--
Michael

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Heikki Linnakangas 2014-06-03 08:33:20 Re: Mentioning CPU for Windows build in docs
Previous Message lev.bukovski 2014-06-03 07:44:52 Re: Prepared statement error with UseServerSidePrepare=1