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