Re: [cfe-users] package build fails at r324504 or later on VS2017
I'm guessing this is a problem with NSIS failing to handle large files though, and I'm not sure there's much we can do about it. On Mon, Feb 19, 2018 at 10:54 PM, masaru tsuchiyama wrote: > But it failed with -DLLVM_ENABLE_PDB=ON option . > > The error message is > File: "lldELF.lib" > Internal compiler error #12345: error mmapping datablock to 21869285. > > Note: you may have one or two (large) stale temporary file(s) left in your > temporary directory (Generally this only happens on Windows 9x). > > > 2018-02-19 21:50 GMT+09:00 Hans Wennborg : >> >> Ah, great. >> >> Reid, seems like you fixed this user's issue. >> >> On Mon, Feb 19, 2018 at 1:45 PM, masaru tsuchiyama >> wrote: >> > It seems the change of the commit was disabled by default at r325296. >> > >> > Regards. >> > >> > >> > 2018-02-19 19:55 GMT+09:00 Hans Wennborg : >> >> >> >> No, I didn't change anything here and I don't think Zach did either. >> >> >> >> On Sun, Feb 18, 2018 at 9:39 AM, masaru tsuchiyama >> >> wrote: >> >> > It didn't happen at r325456. >> >> > Did you fix it? >> >> > >> >> > Regards. >> >> > >> >> > 2018-02-17 5:57 GMT+09:00 masaru tsuchiyama : >> >> >> >> >> >> > Is that a solution to your problem? >> >> >> >> >> >> No. >> >> >> It could be a workaround, but not a solution. >> >> >> I think we need to know the reason why the commit and the option >> >> >> affect >> >> >> the result at least. >> >> >> >> >> >> >> >> >> 2018-02-16 19:05 GMT+09:00 Hans Wennborg : >> >> >>> >> >> >>> On Thu, Feb 15, 2018 at 11:43 PM, masaru tsuchiyama >> >> >>> >> >> >>> wrote: >> >> >>> > Hi, >> >> >>> > >> >> >>> >> Is there any info about what went wrong in NSISOutput.log? >> >> >>> > >> >> >>> > I attach the log. >> >> >>> > >> >> >>> > This is the last part of the log. >> >> >>> > >> >> >>> > File: "clangStaticAnalyzerCheckers.lib" >> >> >>> > >> >> >>> > Internal compiler error #12345: error mmapping file >> >> >>> > (2106828838, >> >> >>> > 33554432) >> >> >>> > is out of range. >> >> >>> > Note: you may have one or two (large) stale temporary file(s) >> >> >>> > left >> >> >>> > in >> >> >>> > your >> >> >>> > temporary directory (Generally this only happens on Windows 9x). >> >> >>> > >> >> >>> > I'm using Win10 Pro Japanese and VS2017 Community Japanese. >> >> >>> > The version of NSIS is 3.02.1. >> >> >>> > >> >> >>> >> Maybe you want to add -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON to your >> >> >>> >> build, >> >> >>> >> though I'm not sure that should make any difference to the pdb >> >> >>> >> files. >> >> >>> > >> >> >>> > If I added the option, the build succeeded. >> >> >>> >> >> >>> Is that a solution to your problem? >> >> >>> >> >> >>> > 2018-02-14 23:06 GMT+09:00 Hans Wennborg : >> >> >>> >> >> >> >>> >> +Zach for r324504 >> >> >>> >> >> >> >>> >> On Tue, Feb 13, 2018 at 1:45 PM, masaru tsuchiyama via cfe-users >> >> >>> >> wrote: >> >> >>> >> > Hello >> >> >>> >> > >> >> >>> >> > llvm build fails at r324504 or later. >> >> >>> >> > I used the attached file to build. (renamed to .txt) >> >> >>> >> > >> >> >>> >> > example: >> >> >>> >> >clang-build.bat ninja x86 update 324806 >> >> >>> >> > >> >> >>> >> > This is the tail of the failure log. >> >> >>> >> > >> >> >>> >> > CPack: Create package using NSIS >> >> >>> >> > CPack: Install projects >> >> >>> >> > CPack: - Install project: LLVM >> >> >>> >> > Creating llvm-ranlib.exe >> >> >>> >> > Creating llvm-lib.exe >> >> >>> >> > Creating llvm-dlltool.exe >> >> >>> >> > Creating clang++.exe >> >> >>> >> > Creating clang-cl.exe >> >> >>> >> > Creating clang-cpp.exe >> >> >>> >> > Creating ../msbuild-bin/cl.exe >> >> >>> >> > Creating lld-link.exe >> >> >>> >> > Creating ld.lld.exe >> >> >>> >> > Creating ld64.lld.exe >> >> >>> >> > Creating wasm-ld.exe >> >> >>> >> > Creating llvm-readelf.exe >> >> >>> >> > CPack: Create package >> >> >>> >> > CPack Error: Problem running NSIS command: "C:/Program Files >> >> >>> >> > (x86)/NSIS/makensis.exe" >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > "C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/project.nsi" >> >> >>> >> > Please check >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/NSISOutput.log >> >> >>> >> > for errors >> >> >>> >> >> >> >>> >> Is there any info about what went wrong in NSISOutput.log? >> >> >>> >> >> >> >>> >> > CPack Error: Problem compressing the directory >> >> >>> >> > CPack Error: Error when generating package: LLVM >> >> >>> >> > FAILED: CMakeFiles/package.util >> >> >>> >> > cmd.exe /C "cd /D C:\Jenkins\workspace\llvm\build && >> >> >>> >> > "C:\Program >> >> >>> >> > Files\CMake\bin\cpack.exe" --config ./CPackConfig.cmake" >> >> >>> >> > ninja: build stopped: subcommand failed. >> >> >>> >> > >> >> >>> >> > I confirmed that the build succeeded by reverting r324504 at >> >> >>> >> > r324806. >> >> >>> >> > >> >> >>> >> > Index: cmake/modules/HandleLLVMOptions.cmake >> >> >>> >> > >> >> >
Re: [cfe-users] package build fails at r324504 or later on VS2017
The official snapshots and releases still only include the toolchain, by passing -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON. On Tue, Feb 20, 2018 at 4:54 PM, Reid Kleckner wrote: > I didn't think we included the .lib files in the NSIS package. Do we do that > now? I know users asked for it, but I thought we stuck with just the > toolchain. > > On Tue, Feb 20, 2018 at 1:13 AM, Hans Wennborg wrote: >> >> I'm guessing this is a problem with NSIS failing to handle large files >> though, and I'm not sure there's much we can do about it. >> >> On Mon, Feb 19, 2018 at 10:54 PM, masaru tsuchiyama >> wrote: >> > But it failed with -DLLVM_ENABLE_PDB=ON option . >> > >> > The error message is >> > File: "lldELF.lib" >> > Internal compiler error #12345: error mmapping datablock to 21869285. >> > >> > Note: you may have one or two (large) stale temporary file(s) left in >> > your >> > temporary directory (Generally this only happens on Windows 9x). >> > >> > >> > 2018-02-19 21:50 GMT+09:00 Hans Wennborg : >> >> >> >> Ah, great. >> >> >> >> Reid, seems like you fixed this user's issue. >> >> >> >> On Mon, Feb 19, 2018 at 1:45 PM, masaru tsuchiyama >> >> wrote: >> >> > It seems the change of the commit was disabled by default at r325296. >> >> > >> >> > Regards. >> >> > >> >> > >> >> > 2018-02-19 19:55 GMT+09:00 Hans Wennborg : >> >> >> >> >> >> No, I didn't change anything here and I don't think Zach did either. >> >> >> >> >> >> On Sun, Feb 18, 2018 at 9:39 AM, masaru tsuchiyama >> >> >> >> >> >> wrote: >> >> >> > It didn't happen at r325456. >> >> >> > Did you fix it? >> >> >> > >> >> >> > Regards. >> >> >> > >> >> >> > 2018-02-17 5:57 GMT+09:00 masaru tsuchiyama : >> >> >> >> >> >> >> >> > Is that a solution to your problem? >> >> >> >> >> >> >> >> No. >> >> >> >> It could be a workaround, but not a solution. >> >> >> >> I think we need to know the reason why the commit and the option >> >> >> >> affect >> >> >> >> the result at least. >> >> >> >> >> >> >> >> >> >> >> >> 2018-02-16 19:05 GMT+09:00 Hans Wennborg : >> >> >> >>> >> >> >> >>> On Thu, Feb 15, 2018 at 11:43 PM, masaru tsuchiyama >> >> >> >>> >> >> >> >>> wrote: >> >> >> >>> > Hi, >> >> >> >>> > >> >> >> >>> >> Is there any info about what went wrong in NSISOutput.log? >> >> >> >>> > >> >> >> >>> > I attach the log. >> >> >> >>> > >> >> >> >>> > This is the last part of the log. >> >> >> >>> > >> >> >> >>> > File: "clangStaticAnalyzerCheckers.lib" >> >> >> >>> > >> >> >> >>> > Internal compiler error #12345: error mmapping file >> >> >> >>> > (2106828838, >> >> >> >>> > 33554432) >> >> >> >>> > is out of range. >> >> >> >>> > Note: you may have one or two (large) stale temporary >> >> >> >>> > file(s) >> >> >> >>> > left >> >> >> >>> > in >> >> >> >>> > your >> >> >> >>> > temporary directory (Generally this only happens on Windows >> >> >> >>> > 9x). >> >> >> >>> > >> >> >> >>> > I'm using Win10 Pro Japanese and VS2017 Community Japanese. >> >> >> >>> > The version of NSIS is 3.02.1. >> >> >> >>> > >> >> >> >>> >> Maybe you want to add -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON to >> >> >> >>> >> your >> >> >> >>> >> build, >> >> >> >>> >> though I'm not sure that should make any difference to the >> >> >> >>> >> pdb >> >> >> >>> >> files. >> >> >> >>> > >> >> >> >>> > If I added the option, the build succeeded. >> >> >> >>> >> >> >> >>> Is that a solution to your problem? >> >> >> >>> >> >> >> >>> > 2018-02-14 23:06 GMT+09:00 Hans Wennborg : >> >> >> >>> >> >> >> >> >>> >> +Zach for r324504 >> >> >> >>> >> >> >> >> >>> >> On Tue, Feb 13, 2018 at 1:45 PM, masaru tsuchiyama via >> >> >> >>> >> cfe-users >> >> >> >>> >> wrote: >> >> >> >>> >> > Hello >> >> >> >>> >> > >> >> >> >>> >> > llvm build fails at r324504 or later. >> >> >> >>> >> > I used the attached file to build. (renamed to .txt) >> >> >> >>> >> > >> >> >> >>> >> > example: >> >> >> >>> >> >clang-build.bat ninja x86 update 324806 >> >> >> >>> >> > >> >> >> >>> >> > This is the tail of the failure log. >> >> >> >>> >> > >> >> >> >>> >> > CPack: Create package using NSIS >> >> >> >>> >> > CPack: Install projects >> >> >> >>> >> > CPack: - Install project: LLVM >> >> >> >>> >> > Creating llvm-ranlib.exe >> >> >> >>> >> > Creating llvm-lib.exe >> >> >> >>> >> > Creating llvm-dlltool.exe >> >> >> >>> >> > Creating clang++.exe >> >> >> >>> >> > Creating clang-cl.exe >> >> >> >>> >> > Creating clang-cpp.exe >> >> >> >>> >> > Creating ../msbuild-bin/cl.exe >> >> >> >>> >> > Creating lld-link.exe >> >> >> >>> >> > Creating ld.lld.exe >> >> >> >>> >> > Creating ld64.lld.exe >> >> >> >>> >> > Creating wasm-ld.exe >> >> >> >>> >> > Creating llvm-readelf.exe >> >> >> >>> >> > CPack: Create package >> >> >> >>> >> > CPack Error: Problem running NSIS command: "C:/Program >> >> >> >>> >> > Files >> >> >> >>> >> > (x86)/NSIS/makensis.exe" >> >> >> >>> >> > >> >> >> >>> >> > >> >> >> >>> >> > >> >> >> >>> >> > >> >> >> >>> >> > "C:/Jenkins/workspace/llvm/build/_CPack_Packages/win32/NSIS/project.nsi" >> >> >> >>
[cfe-users] crashing w/sanitizers
Hi All: I’ve been happily using clang and its various sanitizers for quite a while now, but have recently run into a strange problem, and thought I would ask about it here before posting a bug report (mostly because I don’t have enough detailed information for a bug report as yet). Short version: both Address Sanitizer and Thread Sanitizer builds of my application are crashing — in the case of ASAN I get “ASAN:DEADLYSIGNAL” and that’s all, with TSAN I get a SIGBUS error and an hs_errpid file. (The application is a C++ shared library hosted in a JVM. The JVM is spawned from a C++ executable so that ASAN and TSAN can be linked statically). I’m getting this behavior with clang 5.0.0 and 5.0.1. The funny thing is this happens only my home Linux box, which has aCore i5-2400, while it does not happen on my work machine, which has two Core i7-4770R CPUs. Both are running Centos 6.9, with 16GB RAM. Does this ring a bell for anyone? Any help is much appreciated… Thanks! ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Format of AST entries?
I am attempting to do some basic parsing of the AST using C#. So far I've had success extracting a few things simply by writing some test C++ code, generating an AST for it, making some changes, regenerating an AST, and observing what changes in the AST entries. However, this empirical approach is pretty brutal and requires a lot of questionable assumptions. Is there any documentation that explicitly explains the possible permutations and field meanings of each AST entry type? If so I'd greatly appreciate a link to it. I've done pretty well figuring out the FunctionDecl item and a few others but a document describing them would really be helpful. For example, in the following I know that 'ABCDE' represents the name of the function and 'float (int, char)' represents its data type, but there are two copies of 'float (int, char)' and I'd like to know why and if they both represent the same thing: || `-DeclRefExpr 0x862c118 'float (int, char)' lvalue Function 0x85deae0 'ABCDE' 'float (int, char)' I have similar questions about most of the entry types. Thanks, Ray___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users