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
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180516/6fa19f85/attachment.html>
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<mailto: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<mailto: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/6d9dab0d/attachment.html>