Displaying 20 results from an estimated 1000 matches similar to: "MSBuild incremental builds are broken with LLVM 6 (and beyond)"
2015 Jun 09
2
[LLVMdev] msbuild and clang
Okay, so trying a straight compile of the Python interpreter with clang-cl,
I used the following commands:
cd \python-2.7.10\pcbuild
copy C:\llvm\build\Release\bin\clang-cl.exe cl.exe
rd /q /s amd64
rd /q /s win32-temp-debug
rd /q /s win32-temp-release
rd /q /s x64-temp-debug
rd /q /s x64-temp-release
msbuild /p:Configuration=Release /v:diag /fileLogger pcbuild.sln
(The second line is the one
2015 Jun 08
3
[LLVMdev] msbuild and clang
I'm trying to compile some large programs with clang on Windows (with a
view to compiling to bit code and then running some whole program
optimisations on the bit code).
Take for example the Python 2.7 interpreter:
As is typically the case, the usual build procedure involves running
msbuild which invokes the Microsoft compiler.
The most obvious procedure would then be to substitute
2018 May 16
2
Windows build strangeness
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
2018 May 16
2
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
2015 Feb 01
2
[LLVMdev] Building LLVM with static linking on Windows
I'm trying to build LLVM 3.5.1 on Windows, almost successfully; the
remaining stumbling block is getting static linking for release builds. The
problem is that the .vcxproj is interpreted by msbuild to compile with the
/MD option instead of /MT, as detailed in:
https://stackoverflow.com/questions/28262372/getting-msbuild-to-use-mt-staticrelease
Haven't got any answers on that question,
2018 May 16
1
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
2018 May 16
2
Windows build strangeness
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
2018 May 17
0
Windows build strangeness
>From my own experience this is what I think happens when building the whole
solution through Visual Studio's UI. This also happens for building
individual projects. I assume something similar happens when building via
the command-line, but I rarely do that, so I can't be certain.
1) Visual Studio/MSBuild (I don't know which, but probably MSBuild)
determines the dependency graph of
2018 May 16
0
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 opt
CMake is re-running because
2014 Sep 29
4
[LLVMdev] Windows Installer
I was hoping to not have to build LLVM myself, especially on Windows.
Can anybody help me with the Windows installer?
Failing that, I find the directions for how to compile on Windows hard
to follow? Can I build using Cygwin?
Regards,
Eric
On 9/29/14, 8:11 AM, Rafael Auler wrote:
> I'm not sure about the Windows installer, but if you build and install
> LLVM for Windows from the
2018 May 17
1
Windows build strangeness
It looks like building ZERO_CHECK first to reconstruct the project files as needed, then running msbuild a second time to do the actual build, has solved the problem. At least, last night's run didn't take the usual two tries. Running msbuild twice is a little bit simpler than running cmake explicitly, the way I have my scripts set up, but I'm sure that would work as well.
Thanks
2014 Sep 30
2
[LLVMdev] Windows Installer
I replaced all instances of "$(Platform)" with "x64" for the x64 .props
file and it still fails, so it looks like that guess was wrong as well.
Regards,
Eric
On 9/29/14, 2:11 PM, Eric Mader wrote:
> Quoting doesn't seem to make a difference. Strangely, the Win32
> toolset seems to work. (Where "work" means that clang runs and
> produces a bunch of
2014 Sep 30
2
[LLVMdev] size_t?
I'm getting compile errors because size_t is getting redefined. My
"forced include file" starts with:
#if BUILDING_FOR_WINDOWS
#define NOMINMAX
/* deal with the fact that windef.h also defines BOOL */
#define BOOL WINBOOL
#include <windows.h>
#include <intrin.h>
#undef BOOL
#endif
Looking at the preprocessor expansion of a typical .cpp file, I see that
crtdefs.h
2018 May 16
0
Windows build strangeness
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:
2014 Sep 29
2
[LLVMdev] Windows Installer
Open the file toolset-vs2013.props and you'll understand what's happening
and where the path is set. It tries to fetch the LLVM installation path
from the Windows registry. Just fix this (maybe editing your registry or
editing the .props file, whatever suits you best).
On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote:
> I copied the x64 toolsets by hand and
2014 Sep 29
2
[LLVMdev] Windows Installer
Your install dir has a whitespace. Have you tried quoting? e.g.
<LLVMInstallDir>"C:\Program
Files (x86)\LLVM"</LLVMInstallDir>
Best regards,
Rafael Auler
On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote:
> I changed tooset-vs2013.props to this:
>
> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>
2018 Mar 22
4
[pre-RFC] Data races in concurrent ThinLTO processes
Hello,
I am sending the following proposal to discuss issues and solutions regarding data races in concurrent ThinLTO processes.
This caught my attention when we encountered a race condition in ThinLTO with caching.
While looking into how ThinLTO deals with the problem of cache files reads/writes/deletes I spotted a lot of problems: some of them are related to data races, others - to
2014 Oct 01
2
[LLVMdev] size_t?
We inject a typedef for size_t here:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206
The typedef type is determined by calling getSizeType().
SizeType is (relevantly) calculated in two places:
X86_64
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512
X86_32
2014 Sep 30
2
[LLVMdev] size_t?
Hi Reid,
I copied the x64 toolsets by hand; they got installed to C:\Program
Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly
by install.bat.
I just verified that the LLVM-vs2013 toolset.props is correct.
If it is a bitness problem, perhaps I'm failing to define something
correctly?
Regards,
Eric
On 9/30/14, 11:29 AM, Reid Kleckner wrote:
> This looks
2014 Jun 04
2
opus_multistream_encode_float not working in libopus 1.1
> Have you tried compiling it yourself?
I just installed git for the first time and downloaded all of the
latest source code packages directly from the site. I'm getting the
following every time I try to (re)build any of the projects:
1>------ Build started: Project: opus, Configuration: Release Win32 ------
1> fatal: Not a git repository: 'C:\My