Re: Mentioning CPU for Windows build in docs
От | Michael Paquier |
---|---|
Тема | Re: Mentioning CPU for Windows build in docs |
Дата | |
Msg-id | CAB7nPqSOCDidETAKa0wq8LbaKjqj_5Hhv5AmgRJgmhAGPT=HSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Mentioning CPU for Windows build in docs (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-odbc |
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
В списке pgsql-odbc по дате отправления: