On Tue, Jun 3, 2014 at 6:42 PM, Heikki Linnakangas
<hlinnakangas@vmware.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
