[LLVMdev] 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 <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>