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>
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 <russell.wallace at gmail.com> 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 <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/63e3664b/attachment.html>
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 <russell.wallace at
gmail.com>
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 <
> russell.wallace at gmail.com> 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 <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/d4fd967a/attachment.html>