similar to: [LLVMdev] Errors while building and installation of llvm-1.9

Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] Errors while building and installation of llvm-1.9"

2007 May 17
3
[LLVMdev] 2.0-prerelease build errors
Hi all, I'm building the LLVM 2.0 pre-release on a brand new FreeBSD 6.2 install. Without the bison package installed, the build breaks: $ tar zxf llvm-2.0.tar.gz $ mkdir objdir $ cd objdir $ ../llvm-2.0/configure $ gmake [...] gmake[2]: Entering directory `/usr/home/emil/objdir/utils/TableGen' llvm[2]: Compiling AsmWriterEmitter.cpp for Release build llvm[2]: Compiling
2007 May 17
0
[LLVMdev] 2.0-prerelease build errors
> llvm[2]: Flexing FileLexer.l > llvm[2]: Bison of FileParser.y SKIPPED -- bison not found > llvm[2]: Compiling FileLexer.cpp for Release build > /usr/home/emil/llvm-2.0/utils/TableGen/FileLexer.l:34:24: FileParser.h: No such file or directory > > Is this a packaging issue where FileParser.h was omitted > from the tarball, or does LLVM *need* bison in order to build? No,
2004 Aug 31
2
[LLVMdev] More configure problems
On Mon, 30 Aug 2004 21:27:26 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Mon, 30 Aug 2004 20:48:45 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > When I ran configure after updating, I get various errors. First: > > > > % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc > > checking for a
2004 Oct 13
1
[LLVMdev] Compiling TableGen with Visual Studio
I finally succeded in compiling TableGen with Visual Studio. In the end I made normal solution and project files for VS instead of using Paolo's SConstruct based build system because of my lacking familiarity with SConstruct. One of the main obstacles was getting the FileLexer and FileParser to build correctly. First of all the output file for FileLexer is specified with a %option, which
2004 Oct 23
2
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib
2007 Sep 17
0
[LLVMdev] 2.1 Pre-Release Available (testers needed)
On Fri, Sep 14, 2007 at 11:42:18PM -0700, Tanya Lattner wrote: > LLVMers, > > The 2.1 pre-release (version 1) is available for testing: > http://llvm.org/prereleases/2.1/version1/ I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be stale. I tried building LLVM without bison installed and got: gmake[2]: Entering directory
2007 Sep 18
0
[LLVMdev] 2.1 Pre-Release Available (testers needed)
On Mon, Sep 17, 2007 at 12:25:40PM -0700, Chris Lattner wrote: > On Mon, 17 Sep 2007, Emil Mikulic wrote: > >> The 2.1 pre-release (version 1) is available for testing: > >> http://llvm.org/prereleases/2.1/version1/ > > > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > > stale. I tried building LLVM without bison installed and got:
2007 Sep 17
3
[LLVMdev] 2.1 Pre-Release Available (testers needed)
On Mon, 17 Sep 2007, Emil Mikulic wrote: >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > I suspect the utils/TableGen/FileParser.h.cvs in the tarball may be > stale. I tried building LLVM without bison installed and got: Can you try it again without bison with these files:
2007 Mar 14
1
[LLVMdev] LLVM with Microsoft Visual Studio
Jeff Cohen wrote: > Morten Ofstad wrote: >> Jeff Cohen wrote: >> >>> The recent issues concern the head revision, post 1.9. As no one has >>> ever submitted patches to fix 2005 problems with the 1.9 release, it is >>> safe to say they still exist. >>> >> >> For the 1.5 release I submitted patches that made everything compile
2004 Aug 31
0
[LLVMdev] More configure problems
On Mon, 2004-08-30 at 21:46, Jeff Cohen wrote: > This isn't my day... > > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' > Bisoning FileParser.y > Flexing /usr/home/llvm/obj/../utils/TableGen/FileLexer.l > gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen' > gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' >
2004 Aug 31
0
[LLVMdev] More configure problems
On Mon, 30 Aug 2004 20:48:45 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > When I ran configure after updating, I get various errors. First: > > % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc > checking for a BSD-compatible install... /usr/bin/install -c > checking build system type... i386-unknown-freebsd5.2.1 > checking host system
2004 Oct 25
0
[LLVMdev] Link error with TOOLLINKOPTS=-ldbghelp on MinGW
Henrik Bach wrote: > Hi LLVM'ers > > When linking tblgen tool I get below error message on MinGW. > > I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. > > However, when rearranging library dbghelp to the end of the g++ > line, tblgen gets linked. It seems that the -L path options are specified before the LLVM libraries (libSystem and libsupport) are linked in.
2004 Aug 31
4
[LLVMdev] More configure problems
When I ran configure after updating, I get various errors. First: % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc checking for a BSD-compatible install... /usr/bin/install -c checking build system type... i386-unknown-freebsd5.2.1 checking host system type... i386-unknown-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad
2006 Apr 19
0
[LLVMdev] 1.7 Pre-Release Ready for Testing
On 4/16/06, Tanya Lattner <tonic at nondot.org> wrote: > > I've put the pre-release tar balls here: > http://llvm.org/prereleases/1.7/ > The build failed on i686-pc-linux-gnu. llvm[2]: Flexing FileLexer.l llvm[2]: Compiling FileLexer.cpp for Release build /home/rogelio/Desktop/llvm/utils/TableGen/FileLexer.l: In function 'int Filelex()':
2007 Sep 20
2
[LLVMdev] Building on x86-64
I made my first attempt to build on an x86_64-unknown-linux-gnu system. Is this supposed to work? I get libtools errors (below). The problem seems to be that it finds a 32-bit libltdl rather than the 64-bit libltdl. /home/dag> ls /usr/lib/libltdl.so.3.1.0 /usr/lib/libltdl.so.3.1.0 /home/dag> ls /usr/lib64/libltdl.so.3.1.0 /usr/lib64/libltdl.so.3.1.0 Is this a known problem?
2004 Aug 31
1
[LLVMdev] More configure problems
>From: Jeff Cohen <jeffc at jolt-lang.org> >Date: Mon, 30 Aug 2004 21:46:42 -0700 >FileParser.tab.c: In function `int Fileparse()': >FileParser.tab.c:2043: error: syntax error before `goto' > >The offending lines bison generated are: > >/*----------------------------------------------------. >| yyerrlab1 -- error raised explicitly by an action. |
2004 Aug 18
1
[LLVMdev] tblgen: Assertion failed: "Buffer[Length-1] == '"'", file FileLexer.l, line 114
Hi I've been investigating which characters that cause troubles: Length = 23 WhatsInBuffer=include "../Target.td" assert=false tblgen: Assertion failed: "Buffer[Length-1] == '"'", file FileLexer.l, line 128 idx hex char 0 69 i 1 6E n 2 63 c 3 6C l 4 75 u 5 64 d 6 65 e 7 20 8 22 " 9 2E . 10 2E . 11 2F / 12 54 T 13 61 a 14 72 r 15 67 g 16 65 e 17 74 t 18
2004 Jul 21
0
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source
2007 Mar 12
0
[LLVMdev] LLVM with Microsoft Visual Studio
Morten Ofstad wrote: > Jeff Cohen wrote: > >> The recent issues concern the head revision, post 1.9. As no one has >> ever submitted patches to fix 2005 problems with the 1.9 release, it is >> safe to say they still exist. >> > > For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In