550811 - bustage on Windows x64 build for js-ctypes

Status: RESOLVED FIXED

(Core :: js-ctypes, defect)

Description

[Makoto Kato [:m_kato]]

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.

Comment 1

[Makoto Kato [:m_kato]]

Attachment: patch v1

Comment 2

[(not currently active) Ted Mielczarek]

The msvcc.sh change will need to wind up upstream.

Comment 3

[Makoto Kato [:m_kato]]

landed after merging benjamin's check in.
http://hg.mozilla.org/mozilla-central/rev/c82a85fe6cc3

Comment 4

[[e-mail]]

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?

Comment 5

[(not currently active) Ted Mielczarek]

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.

Comment 6

[[e-mail]]

Ah, ok. Why is the -m64 even required, then?

Comment 7

[Makoto Kato [:m_kato]]

(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.

Comment 8

[[e-mail]]

(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!