search for: fileparsing

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

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

>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. |

I have downloaded the llvm-1.9 from the following link http://llvm.org/releases/download.html#1.9 There are some header files missing and I am getting some compilation errors of the source code when I compiled the llvm-1.9. Can you please send me the correct source code. I am getting the following errors when I compiled the llvm-1.9 on linux-ubuntu with the following command. make -k | tee

> 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,

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:

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' >

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

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:

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

...trying to obtain a cert for mortvm I''ve received the following errors :- adrian@mort:~$ sudo puppetd --server librarian --waitforcert 60 --test Could not autoload "/usr/lib/ruby/1.8/puppet/provider/host/parsed.rb": undefined method `set_options'' for #<Puppet::Util::FileParsing::FileRecord:0xb76cb684 @type=:text> Could not autoload "/usr/lib/ruby/1.8/puppet/provider/mount/parsed.rb": undefined method `set_options'' for #<Puppet::Util::FileParsing::FileRecord:0xb76a7bd0 @type=:text> Could not autoload "/usr/lib/ruby/1.8/puppet/provider/sshke...

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

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

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

The $vmdk value is a directory name in ESX.pm, although the later codes replace '/' with '_', the volume name isn't still friendly, for example, it looks like this: # virsh vol-list pool-dir Name Path ----------------------------------------- esx4.1-rhel6.2-x86_64_esx4.1-rhel6.2-x86_64

On Sep 17, 2007, at 6:59 PM, Emil Mikulic wrote: > 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

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.

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

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

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