[llvm-dev] Windows build strangeness

Wed May 16 13:25:54 PDT 2018

msbuild is is able to re-run cmake if a CMakeLists.txt changes. CMake
adds a special project "ZERO_CHECK" that does this. However, I am not
sure it runs when invoking on the individual projects instead of the
solution.

Try the cmake --build command, which should output the following:

> cmake --build . --target opt
CMake is re-running because
C:/Users/Meinersbur/build/llvm/vc15_debug_x86/tools/polly/CMakeFiles/generate.stamp
is out-of-date.
[...]

Michael

2018-05-16 15:08 GMT-05:00 Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org>:
> I think MSBuild isn't capable of re-running cmake and then reloading the
> project files when CMakeLists.txt changes. It re-runs cmake, but then
> continues the build with the stale projects. That probably explains the
> "PipSqueek.cxx doesn't exist" errors. As for the link error, it could also
> be caused by things like a file rename not getting picked up by MSBuild.
>
> The fix is probably to always run cmake before MSBuild in the nightly job.
> This isn't necessary if you are using ninja or make, if those are options.
>
> On Wed, May 16, 2018 at 12:59 PM via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
>>
>> Here are a couple of representative errors.  C:\Dev\upstream\gitmono is
>> where I keep my clone.
>>
>>
>>
>>        "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target)
>> (1) ->
>>
>>
>> "C:\Dev\upstream\gitmono\wbuild\unittests\Support\DynamicLibrary\SecondLib.vcxproj"
>> (default target) (170:2) ->
>>
>>          c1xx : fatal error C1083: Cannot open source file:
>> 'C:\Dev\upstream\gitmono\llvm-project\llvm\unittests\Suppor
>>
>>        t\DynamicLibrary\PipSqueak.cxx': No such file or directory
>> [C:\Dev\upstream\gitmono\wbuild\unittests\Support\Dyn
>>
>>        amicLibrary\SecondLib.vcxproj]
>>
>>
>>
>>        "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target)
>> (1) ->
>>
>>        "C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj"
>> (default target) (339:2) ->
>>
>>        (Link target) ->
>>
>>          Backend.obj : error LNK2019: unresolved external symbol "public:
>> virtual bool __cdecl mca::FetchStage::isReady
>>
>>        (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced in
>> function "public: void __cdecl mca::Backend::run
>>
>>        (void)" (?run at Backend@mca@@QEAAXXZ)
>> [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj]
>>
>>
>>
>>
>>
>>
>>
>> From: Valentin Churavy [mailto:v.churavy at gmail.com]
>> Sent: Wednesday, May 16, 2018 1:54 PM
>> To: Robinson, Paul
>> Cc: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] Windows build strangeness
>>
>>
>>
>> What kind of missing symbols are you getting?
>>
>> I had to work around dependencies for a Mingw32 build. See
>> https://reviews.llvm.org/D44650
>>
>> On Wed, May 16, 2018, 13:13 via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> I have the git monorepo, and Visual Studio 2015.  I am finding that
>> running a build from the command line with msbuild (as a nightly job)
>> invariably fails on the first try, and succeeds on a retry.
>>
>> The first msbuild command looks like this:
>>
>> msbuild ALL_BUILD.vcxproj /p:Configuration="RelWithDebInfo" /m:6
>> /t:Rebuild
>>
>> This appears to compile everything okay, but invariably fails with
>> some set of link-time errors, reporting missing symbols.  Then I run
>> msbuild again, but without the /t:Rebuild (thus it's a dirty build the
>> second time) and this succeeds.
>>
>> Is there some inadequacy in the CMake dependencies somewhere, so that
>> some links are trying to happen before the libraries are completely
>> finished?  Or just an msbuild issue?
>>
>> I made my nightly script check for errors and run the second round,
>> because it has been happening so consistently, but a proper build
>> system shouldn't require such a workaround.
>>
>> For reference, I generated the sln/project files like this:
>>
>> cmake -G "Visual Studio 14 Win64" -Thost=x64 ^
>>   -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_OPTIMIZED_TABLEGEN=ON ^
>>   -DLLVM_ENABLE_PROJECTS="llvm;clang;clang-tools-extra" ^
>>   ..\llvm-project\llvm
>>
>> (Yes I know the optimized tablegen comes from a separate tree,
>> that's built separately and always works.  It's just the main
>> build that fails.)
>>
>> Thanks,
>> --paulr
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>