[cfe-dev] Heads up: Bug in CMake found when attempting 64-bit build with 32-bit clang-cl.

Sean Silva via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 17 21:23:14 PDT 2015


btw, Hans, Nico: I noticed that we are using a different triple with
`llvm37_32bit/bin/clang-cl.exe -m64` vs `llvm37_64bit/bin/clang-cl.exe`.

http://i.imgur.com/eJXf2XN.png
The `llvm37_32bit/bin/clang-cl.exe -m64` side of the diff is red; the
`llvm37_64bit/bin/clang-cl.exe` side is in green.
The primary difference seems to be:
`llvm37_32bit/bin/clang-cl.exe -m64` chooses `-triple
x86_64-pc-windows-msvc18.0.0`
`llvm37_64bit/bin/clang-cl.exe` chooses `-triple
x86_64-w64-windows-msvc18.0.0`

Not sure if this is intended behavior or not, but just thought I'd let you
guys know, since from what you guys were saying in IRC it sounded like
`llvm37_32bit/bin/clang-cl.exe -m64` is supposed to be equivalent to
`llvm37_64bit/bin/clang-cl.exe`. Like I said, I managed to get it building
with the settings in the OP, so the difference is not a big deal it seems.

-- Sean SIlva

On Thu, Sep 17, 2015 at 9:07 PM, Sean Silva <chisophugis at gmail.com> wrote:

> Hi Nico, Hans, Takumi,
>
> I made it to the bottom of the issue. Turns out that
> CMAKE_C_FLAGS=-m64
> CMAKE_CXX_FLAGS=-m64
> CMAKE_EXE_LINKER_FLAGS=/machine:x64
> is enough to do a 64-bit build correctly with a 32-bit clang-cl (i.e. one
> that targets 32-bit by default). Hooray! The missing piece that I had to
> track down is why I would see `deps = msvc` stuff spewing onto my terminal,
> rather than consumed properly by ninja. I noticed that in rules.ninja,
> CMake had generated:
>
> msvc_deps_prefix = LINK : error LNK2001:
>
> After some hunting in procmon, I found that there was a call to clang-cl
> done during the configure process that *wasn't including -m64*, leading to
> a link error. The text of the link error was then being interpreted as a
> valid output for setting msvc_deps_prefix.
>
> Attached is a quick hack patch for CMake that fixes the issue for me
> locally. Some more details are in the commit message for the patch. It's
> not ideal by any means... my CMake-fu is weak.
>
> Brad, you seem to be roughly our liaison with the CMake community. Do you
> know what the next steps are for getting this fixed in CMake upstream?
>
> -- Sean Silva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150917/aaa88625/attachment.html>


More information about the cfe-dev mailing list