[LLVMdev] Self compiling latest clang from SVN

[Reid Kleckner]

Thanks for trying the self-host, it's something I do locally and we do have
a bot setup for it, but it uses ninja:
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/
Obviously everyone's setup is slightly different and getting diversity in
testing is good.

These undefined symbols are intrinsics that should be taken care of by
clang/lib/Headers/Intrin.h, but somehow that isn't being chosen in
llvm/lib/Support/Host.cpp. I have a feeling that this line is getting
MSVC's builtin header instead of clang's:
#ifdef _MSC_VER
#include <intrin.h>
#endif
When you rename clang-cl.exe to cl.exe, make sure it's in the same bin
directory as clang-cl.exe so that it can find it's resource directory with
these builtin headers.

On Thu, Jun 11, 2015 at 11:31 AM, Russell Wallace <russell.wallace at gmail.com
> wrote:

> I tried checking out the latest llvm/clang from SVN (as of a few hours
> ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a
> version check, so I repeated the technique of compiling with Microsoft C++
> first, then using the resulting clang-cl.exe). It fails with a bunch of
> error messages along the lines of:
>
> LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external symbol
> __faststorefence referenced in function "void __cdecl
> llvm::sys::MemoryFence(void)" (?MemoryFence at sys@llvm@@YAXXZ)
> [C:\llvm-svn\build\utils\FileCheck\FileCheck.vcxproj]
> LLVMSupport.lib(Host.obj) : error LNK2019: unresolved external symbol
> _xgetbv referenced in function "class llvm::StringRef __cdecl
> llvm::sys::getHostCPUName(void)" (?getHostCPUName at sys@llvm@
> @YA?AVStringRef at 2@XZ)
> [C:\llvm-svn\build\utils\FileCheck\FileCheck.vcxproj]
> LLVMSupport.lib(Host.obj) : error LNK2019: unresolved external symbol
> __cpuidex referenced in function "class llvm::StringRef __cdecl
> llvm::sys::getHostCPUName(void)" (?getHostCPUName at sys@llvm@
> @YA?AVStringRef at 2@XZ)
> [C:\llvm-svn\build\utils\FileCheck\FileCheck.vcxproj]
>
> Anyone know what the problem is here?
>
> More generally, is it considered useful to run these sort of tests on the
> SVN version as we go along, or is it more the case that the SVN version is
> expected to have bugs and it would be better to wait for a release
> candidate?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150611/fea29a86/attachment.html>