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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180516/5ff93eff/attachment.html>
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 optCMake 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 >
Martin J. O'Riordan via llvm-dev
2018-May-16 21:07 UTC
[llvm-dev] Windows build strangeness
With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration anytime I do change them. I also use the "Build" rather than "Rebuild" for incremental development. MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Michael Kruse via llvm-dev Sent: 16 May 2018 21:26 To: Reid Kleckner <rnk at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Valentin Churavy <v.churavy at gmail.com> Subject: Re: [llvm-dev] Windows build strangeness 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 optCMake 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 >_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev