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?
> 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?
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.
> 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.
- Heikki
