Обсуждение: Mentioning CPU for Windows build in docs
Hi, While looking at the docs, I noticed that their is no mention to CPU for a Windows build with nmake, but it is essential to provide a value for it or build fails (see for example LINK32_FLAGS in win64.mak). Patch attached somewhat corrects that. Regards, -- Michael
Вложения
On 05/19/2014 09:51 AM, Michael Paquier wrote: > Hi, > > While looking at the docs, I noticed that their is no mention to CPU > for a Windows build with nmake, but it is essential to provide a value > for it or build fails (see for example LINK32_FLAGS in win64.mak). > Patch attached somewhat corrects that. > > 20140519_pgodbc_win_docs.patch > > diff --git a/docs/win32-compilation.html b/docs/win32-compilation.html > index cb63273..7dcf454 100644 > --- a/docs/win32-compilation.html > +++ b/docs/win32-compilation.html > @@ -96,6 +96,10 @@ The following build options may be used: > <td>Release(default), or Debug</td> > </tr> > <tr> > + <td>CPU</td> > + <td>Processor description: x64, x86, AMD64, etc.</td> > + </tr> > + <tr> > <td>PG_INC</td> > <td>$(PROGRAMFILES)\PostgreSQL\9.2\include</td> > </tr> Hmm, are all of those valid values? Does it make sense to use win32.mak with CPU=AMD64, or win64.mak with CPU=x86? If not, I suggest that we just hardcode CPU=x86 in win32.mak and CPU=x64 in win64.mak. CPU=AMD64 seems to be mapped to CPUTYPE=x64 in win64.mak, so ISTM that AMD64 and x64 are just synonyms. This MSDN page lists the valid values: http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile passes /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM with the Windows toolchain, and I have no idea what EBC means, so that leaves just x64 and x86 as the valid options. - Heikki
On Mon, Jun 2, 2014 at 4:26 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 05/19/2014 09:51 AM, Michael Paquier wrote: >> >> Hi, >> >> While looking at the docs, I noticed that their is no mention to CPU >> for a Windows build with nmake, but it is essential to provide a value >> for it or build fails (see for example LINK32_FLAGS in win64.mak). >> Patch attached somewhat corrects that. >> >> 20140519_pgodbc_win_docs.patch >> >> diff --git a/docs/win32-compilation.html b/docs/win32-compilation.html >> index cb63273..7dcf454 100644 >> --- a/docs/win32-compilation.html >> +++ b/docs/win32-compilation.html >> @@ -96,6 +96,10 @@ The following build options may be used: >> <td>Release(default), or Debug</td> >> </tr> >> <tr> >> + <td>CPU</td> >> + <td>Processor description: x64, x86, AMD64, etc.</td> >> + </tr> >> + <tr> >> <td>PG_INC</td> >> <td>$(PROGRAMFILES)\PostgreSQL\9.2\include</td> >> </tr> > > > Hmm, are all of those valid values? Does it make sense to use win32.mak with > CPU=AMD64, or win64.mak with CPU=x86? If not, I suggest that we just > hardcode CPU=x86 in win32.mak and CPU=x64 in win64.mak. Yep, agreed. > CPU=AMD64 seems to be mapped to CPUTYPE=x64 in win64.mak, so ISTM that AMD64 > and x64 are just synonyms. That's the case in the winsdk AFAIK. > This MSDN page lists the valid values: > http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile passes > /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM with > the Windows toolchain, and I have no idea what EBC means, so that leaves > just x64 and x86 as the valid options. Let's just hardcode them and be done. Do you need a patch? -- Michael
On 06/02/2014 10:33 AM, Michael Paquier wrote: >> This MSDN page lists the valid values: >> http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile passes >> /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM with >> the Windows toolchain, and I have no idea what EBC means, so that leaves >> just x64 and x86 as the valid options. > Let's just hardcode them and be done. Do you need a patch? Nah, I'll just do it. Thanks! (I'm trying to set up the toolchain to build Windows binaries and installers ATM, and also trying to clean up and update the docs while I'm at it.) - Heikki
On 06/02/2014 10:41 AM, Heikki Linnakangas wrote: > On 06/02/2014 10:33 AM, Michael Paquier wrote: >>> This MSDN page lists the valid values: >>> http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile passes >>> /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM with >>> the Windows toolchain, and I have no idea what EBC means, so that leaves >>> just x64 and x86 as the valid options. >> Let's just hardcode them and be done. Do you need a patch? > > Nah, I'll just do it. Thanks! > > (I'm trying to set up the toolchain to build Windows binaries and > installers ATM, and also trying to clean up and update the docs while > I'm at it.) So, I started looking at win32.mak and win64.mak, and couldn't resist cleaning them up some more. I removed the CPU argument altogether, but I also removed all references to it within win64.mak, and replaced them with TARGET_CPU. The "setenv /x86" or "setenv /x64" command that you can use in the Visual Studio command line environment to choose the target platform sets TARGET_CPU. So now you can use win64.mak to build 32-bit binaries too, just do "setenv /x86" first. Ideally, we could remove win32.mak altogether. But I don't understand the differences well enough yet to go ahead with that. Thoughts? - Heikki
On Mon, Jun 2, 2014 at 7:48 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 06/02/2014 10:41 AM, Heikki Linnakangas wrote: >> >> On 06/02/2014 10:33 AM, Michael Paquier wrote: >>>> >>>> This MSDN page lists the valid values: >>>> http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile >>>> passes >>>> /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM >>>> with >>>> the Windows toolchain, and I have no idea what EBC means, so that leaves >>>> just x64 and x86 as the valid options. >>> >>> Let's just hardcode them and be done. Do you need a patch? >> >> >> Nah, I'll just do it. Thanks! >> >> (I'm trying to set up the toolchain to build Windows binaries and >> installers ATM, and also trying to clean up and update the docs while >> I'm at it.) > > > So, I started looking at win32.mak and win64.mak, and couldn't resist > cleaning them up some more. > > I removed the CPU argument altogether, but I also removed all references to > it within win64.mak, and replaced them with TARGET_CPU. The "setenv /x86" or > "setenv /x64" command that you can use in the Visual Studio command line > environment to choose the target platform sets TARGET_CPU. So now you can > use win64.mak to build 32-bit binaries too, just do "setenv /x86" first. It is not mandatory to use Visual studio to compile the code as you can do it as well with a simple Windows SDK prompt and nmake. Wouldn't it be better to return an error if TARGET_CPU is not set? > Ideally, we could remove win32.mak altogether. But I don't understand the > differences well enough yet to go ahead with that. Thoughts? I'd vote +1 for removing win32.mak and rename win64.mak to win.mak. The only differences being that win32 can link optionaly to mt, a multithread lib, while win64 has support for gss. It is hard to guess why each option is available only on one Makefile but not the other, so we'd better merge them... -- Michael
Official Windows build no longer uses nmake. The binaries are built using MSBuild. Please look at readme_winbuild.txt or winbuild/readme.txt. regards, Hiroshi Inoue (2014/06/02 20:11), Michael Paquier wrote: > On Mon, Jun 2, 2014 at 7:48 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> On 06/02/2014 10:41 AM, Heikki Linnakangas wrote: >>> On 06/02/2014 10:33 AM, Michael Paquier wrote: >>>>> This MSDN page lists the valid values: >>>>> http://msdn.microsoft.com/en-us/library/5wy54dk2.aspx. (the makefile >>>>> passes >>>>> /MACHINE:{CPUTYPE} to the compiler). We don't support compiling for ARM >>>>> with >>>>> the Windows toolchain, and I have no idea what EBC means, so that leaves >>>>> just x64 and x86 as the valid options. >>>> Let's just hardcode them and be done. Do you need a patch? >>> >>> Nah, I'll just do it. Thanks! >>> >>> (I'm trying to set up the toolchain to build Windows binaries and >>> installers ATM, and also trying to clean up and update the docs while >>> I'm at it.) >> >> So, I started looking at win32.mak and win64.mak, and couldn't resist >> cleaning them up some more. >> >> I removed the CPU argument altogether, but I also removed all references to >> it within win64.mak, and replaced them with TARGET_CPU. The "setenv /x86" or >> "setenv /x64" command that you can use in the Visual Studio command line >> environment to choose the target platform sets TARGET_CPU. So now you can >> use win64.mak to build 32-bit binaries too, just do "setenv /x86" first. > It is not mandatory to use Visual studio to compile the code as you > can do it as well with a simple Windows SDK prompt and nmake. Wouldn't > it be better to return an error if TARGET_CPU is not set? > >> Ideally, we could remove win32.mak altogether. But I don't understand the >> differences well enough yet to go ahead with that. Thoughts? > I'd vote +1 for removing win32.mak and rename win64.mak to win.mak. > The only differences being that win32 can link optionaly to mt, a > multithread lib, while win64 has support for gss. It is hard to guess > why each option is available only on one Makefile but not the other, > so we'd better merge them...
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? The Win32 compilation instructions in the documentation need updating, if we're really going to switch to MSBuild.. - Heikki
On Mon, Jun 2, 2014 at 8:54 PM, Heikki Linnakangas <hlinnakangas@vmware.com> 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? Well... If that counts I'd like to mention that I use nmake now for windows builds... And not only for dev. > The Win32 compilation instructions in the documentation need updating, if > we're really going to switch to MSBuild.. Definitely, it would also be better to merge all the instructions for compilation into a single place. -- Michael
(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. regards, Hiroshi Inoue
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. FWIW, I find the MSBuild stuff to be way more complicated than the nmake makefiles, and it has an extra dependency (PowerShell). I just tried it and I don't like the first impression: the configuration windows launched by editConfiguration.ps1 doesn't fit in my screen. I wonder what options I'm missing. I can edit the configuration.xml file by hand, but I don't find that very comfortable. The nmake files are certainly not perfect - there's a bunch of obsolete cruft there - but let's clean up those rather than throw the whole thing away and start from scratch. That said, I don't have any objection to keeping the MSbuild stuff if you prefer that, but let's continue to maintain win64.mak. I can see one difference now with the MSBuild stuff and the win64.mak method: With the MSBuild method, the output directory is called "AMD64", but with "nmake /f win64.mak", it's called "x64". And for 32-bit builds, they are called "Release" and "x86", respectively. I would prefer nmake's naming scheme for consistency, as it's always <TARGET_CPU>[Debug][ANSI]. Or even better, let's switch to a new scheme that's more clear. I propose that we call the output directories with the following names: x86_Unicode_Release x86_Unicode_Debug x86_ANSI_Release x86_ANSI_Debug x64_Unicode_Release x64_Unicode_Debug x64_ANSI_Release x64_ANSI_Debug For comparison, this is what MSBuild currently uses (in the same order): Release Debug MultibyteRelease MultibyteDebug AMD64 AMD64Debug AMD64ANSIRelease AMD64ANSIDebug That's pretty inconsistent, but I believe it's because of historical reasons. The directory naming was changed from win32.mak to win64.mak, and you kept the names the way you got if you built 32-bit versions with win32.mak and 64-bit versions with win64.mak. - Heikki
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.. - Heikki
(2014/06/03 3:26), 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.
We have ever used win32.mak for 32-bit binaries and win64.mak for
64-bit binaries with vc7(.1) or vc8 for a pretty long time.
The output directories were
Release
MultibyteRelease
AMD64
AMD64ANSI
.
Generated dlls in the directories are taken when installers are
built. I simply kept the correspondence when I introduced the
build system based on MSBuild. The 64-bit output directory has
been "AMD64" because old SDKs set CPU environment variable as
"AMD64" not "x64".
Though I don't object to switch the naming of directories, the
change should also be applied to the installer system.
regards,
Hiroshi Inoue
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 10487 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
(2014/06/03 3:37), Heikki Linnakangas 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. Oops I forgot to remove them? Or I may have left them because they have restricted use for vc9 or before. I don't object to remove them. regards, Hiroshi Inoue -- I am using the free version of SPAMfighter. SPAMfighter has removed 10487 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
(Sending in private) On Tue, Jun 3, 2014 at 3:37 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > 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. Worth noticing that we are getting the following failures in our internal buildweb even if makefile-custom.mak is set up correctly: xalibname.c lib.exe @d:/build/ob/sb-3661041\tmp\nm4D3A.tmp pgenlist.def : error LNK2001: unresolved external symbol DtcOnDisconnect pgenlist.def : error LNK2001: unresolved external symbol EnlistInDtc pgenlist.def : error LNK2001: unresolved external symbol IsolateDtcConn I'll try to see if I can reproduce that on my own dev box. -- Michael
On Tue, Jun 3, 2014 at 3:37 AM, Heikki Linnakangas
<hlinnakangas@vmware.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
On 06/03/2014 06:33 AM, Inoue, Hiroshi wrote: > (2014/06/03 3:26), 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. > > We have ever used win32.mak for 32-bit binaries and win64.mak for > 64-bit binaries with vc7(.1) or vc8 for a pretty long time. > The output directories were > > Release > MultibyteRelease > AMD64 > AMD64ANSI > . > Generated dlls in the directories are taken when installers are > built. I simply kept the correspondence when I introduced the > build system based on MSBuild. The 64-bit output directory has > been "AMD64" because old SDKs set CPU environment variable as > "AMD64" not "x64". > > Though I don't object to switch the naming of directories, the > change should also be applied to the installer system. Ok, renamed! I modified the installer scripts to know that the output directories were changed, IOW the installer scripts still work, but I didn't change the name of the output directory of the installer build itself. So, the .msi files are still generated as /installer/x64/psqlodbc_x64.msi and /installer/psqlodbc.msi - Heikki
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
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
On Tue, Jun 3, 2014 at 2:42 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> 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.
Now the case MSTDC=no works fine, but not the opposite :)
More details here:
cl.exe @C:\Users\ioltas\AppData\Local\Temp\nmB924.tmp
msdtc_enlist.cpp
cl.exe @C:\Users\ioltas\AppData\Local\Temp\nmBB87.tmp
xalibname.c
lib.exe @C:\Users\ioltas\AppData\Local\Temp\nmBBF5.tmp
Creating library .\x64_Unicode_Release\pgenlist.lib and object .\x64_Unicode_
Release\pgenlist.exp
link.exe @C:\Users\ioltas\AppData\Local\Temp\nmBC54.tmp
Creating library .\x64_Unicode_Release\psqlodbc35w.lib and object .\x64_Unico
de_Release\psqlodbc35w.exp
LINK : warning LNK4199: /DELAYLOAD:pgenlist.dll ignored; no imports found from p
genlist.dll
cl.exe @C:\Users\ioltas\AppData\Local\Temp\nmBCA3.tmp
pgxalib.cpp
link.exe @C:\Users\ioltas\AppData\Local\Temp\nmC01F.tmp
Creating library .\x64_Unicode_Release\pgxalib.lib and object .\x64_Unicode_R
elease\pgxalib.exp
link.exe @C:\Users\ioltas\AppData\Local\Temp\nmC03F.tmp
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_free_co
nnect referenced in function "private: __cdecl IAsyncPG::~IAsyncPG(void)" (??1IA
syncPG@@AEAA@XZ)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_set_asy
nc referenced in function "private: __cdecl IAsyncPG::~IAsyncPG(void)" (??1IAsyn
cPG@@AEAA@XZ)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_isolate
referenced in function "private: void * __cdecl IAsyncPG::generateXAConn(bool)"
(?generateXAConn@IAsyncPG@@AEAAPEAX_N@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_connect
referenced in function "private: void * __cdecl IAsyncPG::isolateXAConn(bool,bo
ol)" (?isolateXAConn@IAsyncPG@@AEAAPEAX_N0@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_lock_cn
trl referenced in function "private: void * __cdecl IAsyncPG::getLockedXAConn(vo
id)" (?getLockedXAConn@IAsyncPG@@AEAAPEAXXZ)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_get_pro
perty referenced in function "private: void * __cdecl IAsyncPG::getLockedXAConn(
void)" (?getLockedXAConn@IAsyncPG@@AEAAPEAXXZ)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_get_asy
nc referenced in function IsolateDtcConn
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_one_pha
se_operation referenced in function "public: long __cdecl IAsyncPG::RequestExec(
unsigned long,long)" (?RequestExec@IAsyncPG@@QEAAJKJ@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_two_pha
se_operation referenced in function "public: long __cdecl IAsyncPG::RequestExec(
unsigned long,long)" (?RequestExec@IAsyncPG@@QEAAJKJ@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_set_pro
perty referenced in function "public: long __cdecl IAsyncPG::RequestExec(unsigne
d long,long)" (?RequestExec@IAsyncPG@@QEAAJKJ@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_set_err
or referenced in function "short __cdecl EnlistInDtc_1pipe(void *,struct ITransa
ction *,struct ITransactionDispenser *)" (?EnlistInDtc_1pipe@@YAFPEAXPEAUITransa
ction@@PEAUITransactionDispenser@@@Z)
msdtc_enlist.obj : error LNK2019: unresolved external symbol __imp_PgDtc_create_
connect_string referenced in function "short __cdecl EnlistInDtc_1pipe(void *,st
ruct ITransaction *,struct ITransactionDispenser *)" (?EnlistInDtc_1pipe@@YAFPEA
XPEAUITransaction@@PEAUITransactionDispenser@@@Z)
.\x64_Unicode_Release\pgenlist.dll : fatal error LNK1120: 12 unresolved external
s
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\Bin\amd64\link.exe"' : return code '0x460'
Stop.
--
Michael
On 06/03/2014 02:28 PM, Michael Paquier wrote: > On Tue, Jun 3, 2014 at 2:42 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> 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. > Now the case MSTDC=no works fine, but not the opposite :) It works for me. Did you delete the output directory between builds, to make sure everything gets rebuilt? Hmm, but Debug builds don't work for me, I get a lot of errors like this: socket.obj : error LNK2001: unresolved external symbol __imp___free_dbg That looks somewhat similar to what you got, with the "__imp__" prefix. However, that error isn't new - I got the exact same errors with "nmake /f win64.mak CPU=x64 CFG=Debug" with a checkout from just before my refactorings. So the Debug builds have been broken for a long time, and no-one noticed. win32.mak seemed to work. - Heikki
Hello All, Could someone please, tell me the best way to migrate Sybase to PostGRES from scratch? Many thanks in advance. Regards, Ola > On 3 Jun 2014, at 13:26, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > >> On 06/03/2014 02:28 PM, Michael Paquier wrote: >> On Tue, Jun 3, 2014 at 2:42 AM, Heikki Linnakangas >> <hlinnakangas@vmware.com> wrote: >>> 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. >> Now the case MSTDC=no works fine, but not the opposite :) > > It works for me. Did you delete the output directory between builds, to make sure everything gets rebuilt? > > Hmm, but Debug builds don't work for me, I get a lot of errors like this: > > socket.obj : error LNK2001: unresolved external symbol __imp___free_dbg > > That looks somewhat similar to what you got, with the "__imp__" prefix. > > However, that error isn't new - I got the exact same errors with "nmake /f win64.mak CPU=x64 CFG=Debug" with a checkoutfrom just before my refactorings. So the Debug builds have been broken for a long time, and no-one noticed. win32.makseemed to work. > - Heikki > > > -- > Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-odbc
On Tue, Jun 3, 2014 at 9:26 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 06/03/2014 02:28 PM, Michael Paquier wrote: >> >> On Tue, Jun 3, 2014 at 2:42 AM, Heikki Linnakangas >> <hlinnakangas@vmware.com> wrote: >>> >>> 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. >> >> Now the case MSTDC=no works fine, but not the opposite :) > > > It works for me. Did you delete the output directory between builds, to make > sure everything gets rebuilt? Oops. Sorry for the noise it works. -- Michael