similar to: Newbie question on building with Visual Studio

I am trying to build LLVM from source in FreeBSD 8.4. Here are the steps i carried out 1. Downloaded the source from http://llvm.org/releases/3.8.0/llvm-3.8.0.src.tar.xz 2. Extracted the source into a folder. 3. Created a build directory and inside it ran $ cmake ../llvm-3.8.0.src 4. Started the build using $cmake --build . It throws the following error

Hi all, On my Fedora 10 x86-64 the current svn dies in the following way: /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In function `llvm::TGLexer::getNextChar()': /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: undefined reference to `llvm::TGSourceMgr::FindBufferContainingLoc(llvm::TGLoc) const'

On OS X 10.5.5 I get an error that ld doesn't support -export-dynamic: dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ ../src/configure --prefix=`pwd`/../install && make VERBOSE=1 ... dhcp-172-19-103-185:~/src/llvm/trunk_nolibtool/obj jyasskin$ make VERBOSE=1 for dir in lib/System lib/Support utils lib/VMCore lib tools/llvm-config tools docs; do \ if [ ! -f

Hi, Thanks for the information. Is it possible to compile LLVM 3.8 in FreeBSD 10.x and eventually use/run it on 8.4. Our production environment is running 8.4 and we cannot update it. Thanks, Sushil Pangeni On Wed, Jun 22, 2016 at 2:01 PM, Dimitry Andric <dimitry at andric.com> wrote: > You cannot build any llvm or clang releases after 3.4 on FreeBSD 8.x > natively, as it is not

Are all the records collected as they are parsed, with template parameter substitution and lets, and *then*, after all records are collected, a "pass" is made to calculate the inter-field expressions? Once I understand this, I will add a section to the new guide to explain it. I presume it is the case that this behavior should be publicized. It also appears to be the case that a record

I was a bit confused with what the difference was between the old target_link_libraries(foo bar) and the new target_link_libraries(foo INTERFACE|PRIVATE|PUBLIC bar) To try to find out, I decided to look at the generated build.ninja. The difference that shows up is far fewer order only dependencies. For example build lib/TableGen/CMakeFiles/LLVMTableGen.dir/Error.cpp.o: CXX_COMPILER

I have submitted a patch to Phabricator that includes the TableGen file TGparser.cpp. Now I want to fix a bug in that file. What is the proper procedure so that the two patches don't get screwed up, either in my repository or in the master repository? Please answer as if I'm a git/Phabricator idiot, because, well, I am. I should note that all I did in my repository for the first patch was

For those of you who haven't noticed, I'm planning to commit a major change to the Makefile rules tomorrow evening (Tuesday) if there are no complaints about it between now and then. This needs testing on Darwin. I've heard back from Linux on many platforms and even FreeBSD, which is fantastic, but I'm told that lots of LLVMers are running Darwin and I haven't heard a peep

On 2009-03-25 15:48, Maurice Gittens wrote: > Hi all, > > On my Fedora 10 x86-64 the current svn dies in the following way: > > /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In > function `llvm::TGLexer::getNextChar()': > /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: > undefined reference to >

Hello, Neal > You may want to note that you need glibc-devel.i386 to build. Otherwise you > get error on /usr/include/gnu/stubs-32.h missing. Do you have pure 64 bit system? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

You may want to note that you need glibc-devel.i386 to build. Otherwise you get error on /usr/include/gnu/stubs-32.h missing.

Hello, I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!car(_bli).t> { } #0 0x00007ffff6ebda75 in *__GI_raise

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related to your lisp interpreter :) -Chris > > class

I think I understand the concepts, but I sure would appreciate a specific example, and I appreciate the offer. To make your life harder, could you start with what I should do given that I have not created a branch for the first patch? I just have the six files staged. I have GitHub Desktop installed, if that makes any of the steps easier. Thanks again, and no rush! At 8/10/2020 10:07 AM,

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

Hi LLVMers, I found a bug in TGParser that is causing llvm-tblgen to crash on bad input. The reduced testcase is attached. The output follows: $ ./llvm-tblgen --version Low Level Virtual Machine (http://llvm.org/): LLVM version 3.1svn DEBUG build with assertions. Built Jan 20 2012 (15:46:08). Default target: x86_64-apple-darwin11.2.0 Host CPU: penryn $ ./llvm-tblgen bug.td 0

Avoids trying to create and replace version.h more than once which led to file-locking errors with multicore builds. --- Makefile.am | 1 + win32/VS2015/celt.vcxproj | 48 +++++++++++++++++--------- win32/VS2015/generate_version.vcxproj | 65 +++++++++++++++++++++++++++++++++++ win32/VS2015/opus.sln | 32 ++++++++++++++++-

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

--- win32/VS2015/opus.vcxproj | 2 ++ win32/VS2015/opus.vcxproj.filters | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/win32/VS2015/opus.vcxproj b/win32/VS2015/opus.vcxproj index d9aaa03..f55ea37 100644 --- a/win32/VS2015/opus.vcxproj +++ b/win32/VS2015/opus.vcxproj @@ -852,6 +852,7 @@ <ClInclude Include="..\..\celt\vq.h" /> <ClInclude

Hi Paul, If all you care about is debugging then for now we can just emit a few more debug messages which would help to "trace" the flow. To distinguish traces you can prefix it with some known string. I don't think you really need a 'trace' tag in the language spec for this. Debugging Tablegen has always been a nightmare and I don't think we can ever reach a stage where