Self compiling latest clang from SVN

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Self compiling latest clang from SVN

Russell Wallace
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@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@sys@llvm@@YA?AVStringRef@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@sys@llvm@@YA?AVStringRef@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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Self compiling latest clang from SVN

Reid Kleckner-2
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:
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 <[hidden email]> 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@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@sys@llvm@@YA?AVStringRef@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@sys@llvm@@YA?AVStringRef@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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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:
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 <[hidden email]> 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@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@sys@llvm@@YA?AVStringRef@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@sys@llvm@@YA?AVStringRef@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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Self compiling latest clang from SVN

Russell Wallace
However, I tried a little test file with /showIncludes just now and you're right, it is picking up Microsoft's intrin.h instead of its own. I guess clang has some kind of mechanism whereby it puts its own header directories at the start of the include path? How is that supposed to work? I don't see any commandline options that obviously refer to it; does it have anything to do with this fragment from cmake.rst (the most relevant thing I could find with a search for 'include path' over the entire directory tree)?

``LLVM_INCLUDE_DIRS``
  A list of include paths to directories containing LLVM header files.

On Fri, Jun 12, 2015 at 3:11 AM, Russell Wallace <[hidden email]> wrote:
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 <[hidden email]> 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:
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 <[hidden email]> 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@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@sys@llvm@@YA?AVStringRef@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@sys@llvm@@YA?AVStringRef@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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Self compiling latest clang from SVN

Russell Wallace
Okay, I tracked the problem down as far as a likely -looking function, and I stuck in a line of debug code:

void MSVCToolChain::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
                                              ArgStringList &CC1Args) const {
  if (DriverArgs.hasArg(options::OPT_nostdinc))
    return;

  if (!DriverArgs.hasArg(options::OPT_nobuiltininc)) {
    SmallString<128> P(getDriver().ResourceDir);
    llvm::sys::path::append(P, "include");
    std::cout<<"include path "<<P.c_str()<<'\n';
    addSystemInclude(DriverArgs, CC1Args, P);
  }

Which gave sensible looking output:

include path C:\llvm-svn\build\Release\bin\..\lib\clang\3.7.0\include

... ah! Although the include files are source code, they're in the bin directory, and because I was of necessity doing a clean rebuild, they got deleted at the start of the process, so that's why clang was picking up the Microsoft intrin.h. Haven't tested this theory yet - it takes a while to run the builds - but I think it makes sense. This explains the difference in behaviour between 3.6.1 and 3.7.0. In the former case I was extracting from tarballs, so I extracted an entire second copy of the source tree to work within for the self compile. 3.7.0 was downloaded from SVN which took longer so without really thinking about it, I just tried working within the existing tree. What I should do is copy the source tree over to a fresh copy and try the builds again that way. I'll do that next.

On Fri, Jun 12, 2015 at 3:21 AM, Russell Wallace <[hidden email]> wrote:
However, I tried a little test file with /showIncludes just now and you're right, it is picking up Microsoft's intrin.h instead of its own. I guess clang has some kind of mechanism whereby it puts its own header directories at the start of the include path? How is that supposed to work? I don't see any commandline options that obviously refer to it; does it have anything to do with this fragment from cmake.rst (the most relevant thing I could find with a search for 'include path' over the entire directory tree)?

``LLVM_INCLUDE_DIRS``
  A list of include paths to directories containing LLVM header files.

On Fri, Jun 12, 2015 at 3:11 AM, Russell Wallace <[hidden email]> wrote:
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 <[hidden email]> 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:
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 <[hidden email]> 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@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@sys@llvm@@YA?AVStringRef@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@sys@llvm@@YA?AVStringRef@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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Self compiling latest clang from SVN

Russell Wallace
Yes, doing the build from a fresh copy of the tree works with no errors - in particular, the __try and Error problems I hit doing the self build with 3.6.1 seem to have been fixed.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev