[LLVMdev] Self compiling latest clang from SVN

[Russell Wallace]

Makes sense, yeah, trying something in a different environment is usually a
good way to find problems. I had indeed moved the renamed clang-cl.exe to a
different directory, but when I move it back into its home directory and
retry the build, I get the same errors.

On Thu, Jun 11, 2015 at 11:16 PM, Reid Kleckner <rnk at google.com> wrote:

> 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/20150612/4dba42ec/attachment.html>