search for: llee

...: SysUtils.c: In function `executeProgram': SysUtils.c:119: error: `RTLD_NEXT' undeclared (first use in this function) SysUtils.c:119: error: (Each undeclared identifier is reported only once SysUtils.c:119: error: for each function it appears in.) make[2]: *** [/Users/senatorned/llvm/tools/llee/Debug/SysUtils.lo] Error 1 make[1]: *** [llee/.makeall] Error 2 make: *** [all] Error 1 I was wondering if there was an obvious issue here. Thanks, --Kevin

On Wed, 2004-08-04 at 12:21, John Criswell wrote: > In regards to Misha's comments about the automatic execution of bytecode > files, there are several ways to do it: > > 1) Have bytecode files start with #!<JIT/llee/whatever> (portable) > 2) Encapsulate with ELF > 3) Register the type with the kernel (Linux only) > > I don't really care for the llee approach, as it can be broken with > subsequent LD_PRELOADs, requires that I enter an alternative execution > environment, and requires...

...rogram': > SysUtils.c:119: error: `RTLD_NEXT' undeclared (first use in > this function) > SysUtils.c:119: error: (Each undeclared identifier is reported > only once > SysUtils.c:119: error: for each function it appears in.) > make[2]: *** > [/Users/senatorned/llvm/tools/llee/Debug/SysUtils.lo] Error 1 > make[1]: *** [llee/.makeall] Error 2 > make: *** [all] Error 1 llee has been removed from LLVM CVS. If you remove its entry from your llvm/tools/Makefile you should be ok. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...utable files. I would like to be able to run bytecode files directly, the same way I can run a shell script, Python program, or ELF executable directly. I think having to specify an interpreter on the command line (like java program.class) or having to enter a different execution environment (llee /bin/sh) is inconvenient and doesn't integrate into the system as well as it could. 2) Integration with system tools. It would be nice if a common set of tools could manipulate bytecode files. Having the system ar, nm, and file programs work on bytecode and native code object files would...

Reid Spencer wrote: > On Wed, 2004-08-04 at 12:21, John Criswell wrote: > >>In regards to Misha's comments about the automatic execution of bytecode >>files, there are several ways to do it: >> >>1) Have bytecode files start with #!<JIT/llee/whatever> (portable) >>2) Encapsulate with ELF >>3) Register the type with the kernel (Linux only) >> >>I don't really care for the llee approach, as it can be broken with >>subsequent LD_PRELOADs, requires that I enter an alternative execution >>environ...

On Wed, 2004-08-04 at 08:24, John Criswell wrote: > o Configuration Files > > If it isn't too much trouble, I think we should go with XML for the > following reasons: > > 1) We wouldn't need to implement a parsing library. There are several > XML parsing libraries available, and I'm guessing that they're available > in several different programming

Dear All, I thought I would chime in with some ideas and opinions: o Configuration Files If it isn't too much trouble, I think we should go with XML for the following reasons: 1) We wouldn't need to implement a parsing library. There are several XML parsing libraries available, and I'm guessing that they're available in several different programming languages (Reid, am I

LLVMers, Since there's been little feedback on the design document I sent out, some decisions are being made in order to progress the work. If you have strong feelings about any of these, voice them now! 1. Name = llvmcc 2. The config file format will resemble Microsoft .ini files (name=value in sections) 3. -O set of options will control what gets done and what kind of output is

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached