similar to: [LLVMdev] Self compiling latest clang from SVN

Makes sense, yeah, trying something in a different environment is usually a good way to find problems. I had indeed moved the renamed clang-cl.exe to a different directory, but when I move it back into its home directory and retry the build, I get the same errors. On Thu, Jun 11, 2015 at 11:16 PM, Reid Kleckner <rnk at google.com> wrote: > Thanks for trying the self-host, it's

Hello, when I build llvm from git source, some errors occured. 80>asan_new_delete.obj : error LNK2019: unresolved external symbol "void * __cdecl MemalignFromLocalPool(unsigned __int64,unsigned __int64)" (?MemalignFromLocalPool@@YAPEAX_K0 at Z)， "void * __cdecl operator new(unsigned __int64)" (??2 at YAPEAX_K@Z)

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

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

Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at

I assume you are using Visual Studio as your build tool? The LLVM project set turns into a bunch of Visual Studio project files, and my experience has been that they do not always coordinate correctly. Often just running the build again will solve a problem like this. I'm not really familiar with the sanitizers so I don't have any ideas about the specific error, if re-running the build

I'm trying to get clang 3.6.1 to compile itself on Windows, using this command line: msbuild /p:Configuration=Release /p:CLToolExe=clang-cl.exe /p:CLToolPath=c:\llvm\build\Release\bin\ /p:TrackFileAccess=false /p:Platform="x64" /fileLogger ALL_BUILD.vcxproj It barfed on an occurrence of __try but that was only in a test file so I commented it out and retried. Now it's getting

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:

I used to build llvm/clang on windows a lot, and never had any issues. But I never built asan on windows, maybe asan just doesn't build on windows? On Tue, Mar 12, 2019 at 7:14 PM mirchd via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am using Visual Studio 2017, > I re-running cmake and rebuild the project but it still has the unresolved link error. > > thanks

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

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

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

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

Hello all! Please forgive me if this is the wrong mailing list for my question. First off, I am on Windows and using git bash for everything: $ uname MINGW32_NT-6.2 I am attempting to essentially do the kalidescope example. I have copied the code verbatim from the full code listing and am running the following command: $ clang-cl toy.cpp deps/llvm/build/Debug/lib/*.lib //MDd -o toy.exe -I

my build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) my build steps: open VS2017 x64 developer command prompt cd D:\projects\fun\jit_tests mkdir llvm cd llvm git clone https://github.com/llvm-mirror/llvm mkdir llvm-build cd llvm-build cmake -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON

>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

Is this actually the case? I can't find it documented anywhere on MSDN or the rest of the internet. --Owen On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the

Hi, Here are 3 suggested patches. 1. Build test for cmake and run the test in gitlab-ci. 2. Disable the message box on Windows on abort that cause test hangs in CI. 3. Build time improvement by removing unnecessary includes of stdio.h in production code and change to a lighter header intrin.h -> intrin0.h (windows only). Attached screenshot of measurement but it resulted in 14%

Sorry about that, let me check the correct version for the intrin0.h include guard. //Marcus ________________________________ From: Ralph Giles <giles at thaumas.net> Sent: Thursday, June 11, 2020 19:31 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches Speaking of needing more complete ci feedback, the intrin0.h

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