Closed Bug 550811 Opened 12 years ago Closed 12 years ago
bustage on Windows x64 build for js-ctypes
After landing bug 538216, there is three problems. - since uname in mozilla-build is 32-bit process, uname cannot return correct host. So we should add --build and --host for configure of libffi - msvcc.sh needs -m64 for x64 compiler. - disable some warnings (different size cast etc) due to -WX argument.
Attachment #431031 - Flags: review?(ted.mielczarek)
Attachment #431031 - Flags: review?(ted.mielczarek) → review+
The msvcc.sh change will need to wind up upstream.
landed after merging benjamin's check in. http://hg.mozilla.org/mozilla-central/rev/c82a85fe6cc3
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Summary: bustage on Windows x64 buiild for js-ctypes → bustage on Windows x64 build for js-ctypes
So, hang on. Question. The original author of msvcc.sh had a case for -m64, which translated the flag into calling cl64.exe and link64.exe (or something like that; maybe it was cc and link from the separate VC directory where the 64bit tools are installed). Is that not required now? Do cl and link know that -m64 means "call the 64bit versions"? Or did MS just roll cl64 and link64 into cl and link directly?
When building for x64 on Windows, we require that you use a different MozillaBuild batch file, which puts the x64 compilers (they're separate binaries) in your PATH.
Ah, ok. Why is the -m64 even required, then?
(In reply to comment #6) > Ah, ok. Why is the -m64 even required, then? MASM for x64 is ml64.exe, not ml.exe. msvcc.sh sets ml is ml64.exe if using -m64.
(In reply to comment #7) > MASM for x64 is ml64.exe, not ml.exe. msvcc.sh sets ml is ml64.exe if using > -m64. Oh, duh. I thought I removed that bit when I wrote the wrapper. Evidently I left it in. :) Thanks!
Target Milestone: --- → mozilla1.9.3a3
You need to log in before you can comment on or make changes to this bug.