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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150611/0fbeca55/attachment.html>
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>
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>