[cfe-dev] Building Clang/LLVM with VS2013 for x86 & x64 - problems and questions

Wed Mar 25 19:19:02 PDT 2015

I've reset everything in my working directories to use LF not CRLF and
rebuilt everything and ...

I get 147 unexpected failures and I believe they're all of the form "fatal
error: could not acquire lock file for module 'xxx'".

So I've done something stupid with my setup or didn't clean up from a
previous run properly or something ... but what?

(Reminder:  This is Windows, Visual Studio 12 2013 Win64.)

-- David Bakin

On Wed, Mar 25, 2015 at 9:02 AM, Reid Kleckner <rnk at google.com> wrote:

> My theory is that you have checked out the tests with DOS line endings,
> and they don't pass that way.
>
> This C++11 raw string failure, for example, shows an extra carriage return
> in the string literal:
> """
> R:\Sources\llvm\tools\clang\test\CodeGen\string-literal.c:91:18: error:
> expected string not found in input
>  // CHECK-CXX11: private unnamed_addr constant [8 x i8] c"abc\0Adef\00",
> align 1
>                  ^
> <stdin>:23:1: note: scanning from here
> @.str16 = private unnamed_addr constant [9 x i8] c"abc\0D\0Adef\00", align
> 1
> ^
> <stdin>:23:11: note: possible intended match here
> @.str16 = private unnamed_addr constant [9 x i8] c"abc\0D\0Adef\00", align
> 1
>           ^
> """
>
> Many other tests fail with messages like this:
> error:
> 'R:\Sources\llvm\tools\clang\test\ARCMT\whitelisted/header1.h.result' is
> different than 'C:\TEMP\header1.h-5c694d..h'
>
> That suggests that the test compared golden expected test result files
> with carriage returns with output written by clang, which will probably not
> have carriage returns.
>
> On Tue, Mar 24, 2015 at 9:52 PM, David Bakin <davidbak at gmail.com> wrote:
>
>> Thanks for your help.  I've got clang built now ... and I'm trying to
>> confirm it works.
>>
>> I've built an x64 version using the Visual Studio 2013 toolchain (as I
>> described previously).  Following your suggestions I eliminated compiler-rt
>> and left llvm-shlib turned off (for the latter, I didn't know what I was
>> doing when I turned it on).
>>
>> The unit tests for clang (built into ...\tools\clang\unittests) all run
>> successfully.  I then tried to run tests using the command line "test
>> harness" described here
>> <http://clang.llvm.org/hacking.html#testingCommands> even though I'm not
>> exactly sure what tests these are.  The "test harness" required a little
>> tweaking in the cfg files but I got it to run and the summary of results is:
>>
>>
>> ********************
>> Unresolved Tests (1):
>>     Clang :: Index/annotate-comments.cpp
>>   Expected Passes    : 6460
>>   Expected Failures  : 20
>>   Unsupported Tests  : 178
>>   Unresolved Tests   : 1
>>   Unexpected Failures: 174
>>
>>
>> So I'm not sure what this means but it probably isn't good.  "Unexpected
>> Failures" seems awfully high - in fact, I assume that any number >0 is
>> bad.
>>
>> Any ideas on these failures?  (I've attached the log file in case you're
>> interested in looking at it.)  Alternatively, are there other ways to test
>> my built Clang?  (I'm not sure what I can do without compiler-rt.) Thanks!
>> -- David
>>
>> On Tue, Mar 24, 2015 at 11:09 AM, Chris Bieneman <cbieneman at apple.com>
>> wrote:
>>
>>>
>>> On Mar 24, 2015, at 9:30 AM, Reid Kleckner <rnk at google.com> wrote:
>>>
>>> On Mon, Mar 23, 2015 at 5:22 PM, David Bakin <davidbak at gmail.com> wrote:
>>>
>>>> Hi!  I'm new to Clang/LLVM and I'm trying to use Clang as a
>>>> parser/semantic analyzer for a tool I'm trying to write (details on request
>>>> if you'd like).  I'm having trouble building, having following directions
>>>> from the Clang site, the book "Getting Started with LLVM Core Libraries",
>>>> and a couple of other sites mashed together.
>>>>
>>>> a) Using cmake-gui and selecting "Visual Studio 12 2013" I got a set of
>>>> VS project files that only had a Win32 configuration, no x64.  So to build
>>>> x64 it must be necessary to select generator "Visual Studio 12 2013
>>>> Win64"?  And therefore 32-bit vs 64-bit determined by the "generator" and
>>>> not by LLVM_TARGETS_TO_BUILD (which apparently only has X86 and not also
>>>> X64)?
>>>>
>>>
>>> Right, we don't support generating a single VS solution that supports
>>> building LLVM in both 32 and 64-bit.
>>>
>>>
>>> I could be wrong, but I actually think this is a painful limitation of
>>> CMake. I believe CMake implements Win32 and Win64 as different generators
>>> rather than a configure-time setting, which would make this very difficult
>>> to support. Conversely OS X’s multi-arch support is done via a configure
>>> time variable (CMAKE_OSX_ARCHITECTURES). Oddly enough I find that to be a
>>> terrible name because it really just sets the clang -arch flag, and it
>>> works for OS X and iOS, and it should work for Linux too if you use clang
>>> (although I’ve never tested it).
>>>
>>>
>>> LLVM_TARGETS_TO_BUILD controls the set of backends to build, not the
>>> architecture you are currently targeting. Because x86 and x86_64 are so
>>> similar, all the code for both is part of the X86 target. Therefore, there
>>> is no separate X64 target, and you can just enable the X86 backend.
>>>
>>> b) That set of project files didn't build DEBUG - I got errors from
>>>> projects RTAsan_dynamic.i386 and RTAsan.i386 that they don't build DEBUG
>>>> (only RELEASE). (Message from asan_win.cc in both cases.)  Can I just
>>>> remove the DEBUG builds from those two projects, thereby building them for
>>>> release even in the debug build?  And, for curiosity, what is the actual
>>>> limitation there?
>>>>
>>>
>>> You don't need to build compiler-rt to build a semantic analyzer, so I
>>> would remove it from your checkout, honestly.
>>>
>>> ASan doesn't support using the debug CRTs because they greatly
>>> complicate heap interception. For now, ASan should probably just force the
>>> usage of the release CRT regardless of what the user chose. Eventually we
>>> should support the debug CRT when we figure out proper interception.
>>>
>>>
>>>> c) That set of project files also had an error building
>>>> clang_rt.asan-dynamic.i386 with LINK.EXE complaining about a bunch of
>>>> switches (that look to me like compiler switches).
>>>>
>>>> 18>LINK : warning LNK4044: unrecognized option '/Oy-'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/GS-'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/Zi'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/wd4146'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/wd4291'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/wd4391'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/wd4722'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/wd4800'; ignored
>>>> 18>LINK : warning LNK4044: unrecognized option '/GR-'; ignored
>>>>
>>>>
>>>> What's the fix for that?
>>>>
>>>
>>> It's not fixed yet. :) As a workaround, don't build compiler-rt, I don't
>>> think you need it.
>>>
>>>
>>>> d) Finally, I also tried configuring an x64 build using generator
>>>> "Visual Studio 12 2013 Win64" but cmake-gui complained at the selections I
>>>> made as follows:
>>>>
>>>>
>>>> CMake Error at tools/llvm-shlib/CMakeLists.txt:48 (message):
>>>> Auto-generation not implemented for Win32 without GNU utils. Please
>>>> specify LLVM_EXPORTED_SYMBOL_FILE.
>>>>
>>>>
>>>> What's the proper way to fix that?  By which I mean ... is there some
>>>> kind of more complete documentation of the use of CMake in LLVM than
>>>> http://llvm.org/docs/CMake.html (the option LLVM_EXPORTED_SYMBOL_FILE
>>>> doesn't appear on that page and anyway doesn't sound like that's the real
>>>> problem)?
>>>>
>>>
>>> The LLVM_EXPORTED_SYBMOL_FILE is a variable you set to the path of a
>>> file containing the export list you want to pass to the linker. I’m not
>>> aware of anyone using llvm-shlib (LLVM_BUILD_DYLIB) on Windows, so I don’t
>>> know how functional that build tooling will be. If you need dlls rather
>>> than static libraries you might try using the BUILD_SHARED_LIBS option
>>> instead.
>>>
>>> -Chris
>>>
>>>
>>> Don't enable LLVM_BUILD_LLVM_DYLIB if you don't need it. Maybe we should
>>> document how this works better.
>>>
>>>
>>>> I hope all of you more experienced LLVM developers will put up with a
>>>> newbie with newbie questions for awhile.  Thanks in advance! (And let me
>>>> know if there's a better place to get questions answered, perhaps SO?)
>>>>
>>>> -- David Bakin
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150325/43cd285b/attachment.html>