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 10:42:53
Message-ID: CAB7nPqSOCDidETAKa0wq8LbaKjqj_5Hhv5AmgRJgmhAGPT=HSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

On Tue, Jun 3, 2014 at 6:42 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 06/03/2014 11:04 AM, Michael Paquier wrote:
>>
>> When building with this new infrastructure, I am seeing a couple of
>> failures with MSDTC:
>
>
> By new infrastructure, I assume you mean "nmake /f win64.mak" and not the
> MSBuild stuff?
Yep.

>> 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
> Hmm. There was a check in win64.mak for nmake version "6.00.9782.0", which I
> removed in commit f6ea5c07d. I didn't think anyone would care about such an
> old version. How old is that nmake version? Do we care about supporting it?
It is not that old, it is the one of winsdk 7.0 AFAIK.

> Even if we still care about that version, checking for that exact minor
> version seemed wrong. And the check actually just forcibly set MSDTC=no when
> building with that version, which also seemed wrong; I would expect to get
> an error if you try to build a configuration that cannot be supported, to
> alert the user that he's not getting what he wanted.
Definitely.

>> 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.
>
>
> Fixed, I think. AFAICS that library was always passed to the linker command
> line regardless of MSDTC setting, even before my changes, which is wrong. I
> changed it so that it's only passed to the linker when MSDTC=yes. I wonder
> why it didn't fail before, but should be fixed now anyway.
I think you forgot to push your patch :)
--
Michael

In response to

Browse pgsql-odbc by date

  From Date Subject
Next Message Walter Couto 2014-06-03 10:56:54 Re: Problem retrieving a numeric(38,0) value as SQL_NUMERIC_STRUCT if value needs to use all 16 SQLCHAR elements of the val array
Previous Message Heikki Linnakangas 2014-06-03 09:42:37 Re: Mentioning CPU for Windows build in docs