similar to: [LLVMdev] Bytecode Library Names

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.

Command from LLVM CFE bootstrap sequence at FreeBSD: gmake -C runtime install-bytecode terminated with error (verbose mode): --8X------------------------------------------------------- llvm[2]: Installing Debug Bytecode Archive /usr/home/wanderer/pkg/build/llvm/night/cfe/bin/../lib/libcrtend.a /usr/bin/install -c -D /usr/home/wanderer/pkg/build/llvm/obj/Debug/lib/libcrtend.bca

Hi Jeff and others, When building the llvm runtime, I always get this error message: 'Can't destroy file: The process cannot access the file because it is being used by another process.' The file is destoyed anyway. I think that the the real error is the path for the file (*/\file.tmp). However, I can't find the bug in the source. Do you have any clue?:

Ryan M. Lefever wrote: > I am trying to use LLVM as a source to source C compiler. I use > llvm-gcc to convert file.c->file.bc. Then I use opt to run my own > compiler passes to convert file.bc->file.opt.bc. Then I use llc to > convert file.opt.bc->file.opt.c. Now, I want to use normal gcc to > compile file.opt.c into an executable. However, I'm getting the

It looks like what you're getting is a sharing violation. Although, I don't understand why. The llvm-ar.exe when its building an archive file always builds it in a temporary. Only when that is complete does it remove the old one and rename the temporary. Perhaps this is a result of doing parallel build and the "lib3.tmp" file (that name looks wrong to me) is being accessed by

Hi Reid, I don't think I've initiated a parallel build by this command: ------------------------ make TOOLLINKOPTSB+=-ldbghelp TOOLLINKOPTSB+=-lpsapi LDFLAGS+='-Wl,--no-keep-memory' -r VERBOSE=1 ------------------------ Henrik. >From: Reid Spencer Date: Wed, 26 Jan 2005 12:05:51 -0800 > >It looks like what you're getting is a sharing violation. Although, I

I am trying to use LLVM as a source to source C compiler. I use llvm-gcc to convert file.c->file.bc. Then I use opt to run my own compiler passes to convert file.bc->file.opt.bc. Then I use llc to convert file.opt.bc->file.opt.c. Now, I want to use normal gcc to compile file.opt.c into an executable. However, I'm getting the following errors: test.opt.c:89: warning:

Vladimir, Thanks for the note. Unfortunately, the install approach that we're using in the makefiles is a bit broken, based on Linux install program. We'll get this cleaned up soon so that it works on multiple unixes. Reid. On Thu, 2005-02-17 at 14:48, Vladimir Merzliakov wrote: > Command from LLVM CFE bootstrap sequence at FreeBSD: > gmake -C runtime install-bytecode >

You should probably pull in some folks who implemented/maintain the feature for Darwin. I guess they aren't linking this info, but only communicating in the object file between tools - maybe they flag these sections (either in the object, or by the linker) as ignored/dropped during linking. That semantic could be implemented in ELF too by marking the sections SHF_IGNORED or something

Hi Mircea, If you use an ordinary linker that concatenates .llvmbc sections, you can use this code to get the size of each bitcode module. As far as I know, there's no clean way to separate the .llvmcmd sections without making assumptions about what options were used. // Given a bitcode file followed by garbage, get the size of the actual // bitcode. This only works correctly with some kinds

Hi Peter It is not currently related because we started the implementation before Thin-LTO gets proposed in the community but our "__LLVM, __bitcode" section is pretty much the same as ".llvmbc" section. Note ".llvmbc" doesn't really follow the section naming convention for MachO objects. I am hoping to unify them during the upstream of the implementation.

>From: Reid Spencer Date: Wed, 26 Jan 2005 12:23:49 -0800 > >Nope, unless "make" is an alias for "make -j 4" (like I have) make is make for me. > >Could you try using TOOL_VERBOSE=1 with make to get more output ? I've attached an output. Henrik. >Did you try just running the llvm-ar command by itself ? >If not, could you and give it the V (capital

On Sun, Feb 26, 2006 at 10:00:18PM -0800, Wink Saville wrote: > Thanks for the info, you've confirmed what I was trying to do, but when > I compile: [snip] > without "-c" (llvm-gcc t1.c -o t1) the dissassembled bytecode does not > call __main: __main() is used to run static constructors and destructors, so if you're compiling without -c, LLVM knows all the files

Robert, Thanks for the info, you've confirmed what I was trying to do, but when I compile: ----------------------- #include <stdio.h> int main(int argc, char *argv[]) { printf("yo\n"); return 0; } ----------------------- without "-c" (llvm-gcc t1.c -o t1) the dissassembled bytecode does not call __main: ----------------------- ; ModuleID =

Misha Brukman wrote: > On Sun, Feb 26, 2006 at 10:00:18PM -0800, Wink Saville wrote: > > [snip] > If you're using -c, you're telling LLVM that there are other modules you > will link into the executable. Thus, LLVM does not know whether there > will be static ctors/dtors to run or not, so there's the call to > __main() from main. > > __main() gets

On Apr 25, 2006, at 8:56 AM, John Criswell wrote: > Ryan M. Lefever wrote: >> I am trying to use LLVM as a source to source C compiler. I use >> llvm-gcc to convert file.c->file.bc. Then I use opt to run my own >> compiler passes to convert file.bc->file.opt.bc. Then I use llc >> to convert file.opt.bc->file.opt.c. Now, I want to use normal gcc

> Only thing I can think of is that your "platform" link is missing. > make sure "platform is a symbolic link to your platform's subdirectory > in the llvm/lib/System directory. If you're on FreeBSD then: > > ln -s FreeBSD platform > > this should have been done for you when you configured. My fault. I make cvs update llvm and AFTER remove build

On Thu, Jan 17, Richard W.M. Jones wrote: > On Wed, Jan 16, 2013 at 05:51:53PM +0100, Olaf Hering wrote: > > On Mon, Jan 14, Olaf Hering wrote: > > > This is a first attempt to build libguestfs with just a ocaml bytecode > > > compiler. The three tools written in ocaml will be build only when an > > > ocamlopt compiler is available. > > Here is a more

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=GB2312" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Yes, I checked that envvar, and it is set.<br> The error msg when compiling a .c

> Hi LLVMDev, > > The GCC frontend for LLVM inserts a call to a __main() in the > main() function. Whats the purpose of this? And which LLVM > library do I need to link to satisfy the reference? __main is used primarily to call static constructors. The way you satisfy this dependency is to link the bytecode file against crtend.o (aka libcrtend.bc). This is normally accomplished