similar to: [LLVMdev] How do you Build LLVM Statically Linked?

On Tuesday 29 April 2008 14:52:49 David J.A. Koogler wrote: > Everyone, > > I would like to build the LLVM toolchain and the GCC front end as > statically linked executables, but I do not see a configure > option to set this. A quick check of the FAQ and build documents > comes up empty. Is there a linker switch setting or environment > variable for the Makefile? > >

Anders Johnsen wrote: > I think there is a > > ./configure --enable-static > > switch - have you tried that? Yes, but that only seems to force building static libraries, not statically linked tools. Kenneth Boyd wrote: > The --disable-shared option to configure should work (like it does for > most configure-scripted projects). No, I tried that and still got

On Sunday 27 April 2008 00:48:00 Gordon Henriksen wrote: > On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > > Hi Gordon, > > > > Thanks a lot for the feedback. I can see I've been way to > > concentrated on how > > llvm is build, then on this particular patch. I've done the changes > > you have > > suggested and it's now a lot nicer and

On Sunday 27 April 2008 01:33:31 Gordon Henriksen wrote: > On Apr 26, 2008, at 19:09, Anders Johnsen wrote: > > On Sunday 27 April 2008 00:48:00 Gordon Henriksen wrote: > >> On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > >>> +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > >>> unsigned align) { > >>> + CallSite Call =

On Apr 26, 2008, at 19:09, Anders Johnsen wrote: > On Sunday 27 April 2008 00:48:00 Gordon Henriksen wrote: > >> On Apr 26, 2008, at 17:41, Anders Johnsen wrote: >> >> >>> +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, >>> unsigned align) { >>> + CallSite Call = CallSite(unwrap<Instruction>(Instr)); >>> +

On Apr 28, 2008, at 11:07, Anders Johnsen wrote: > Should hopefully be the last one :) Looks great. Applied r50360: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061696.html Thansk Anders! — Gordon

On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > Hi Gordon, > > Thanks a lot for the feedback. I can see I've been way to > concentrated on how > llvm is build, then on this particular patch. I've done the changes > you have > suggested and it's now a lot nicer and cleaner! > > Please do say, if there is anything else. Nice. Just a few small

Hi Gordon, Thanks a lot for the feedback. I can see I've been way to concentrated on how llvm is build, then on this particular patch. I've done the changes you have suggested and it's now a lot nicer and cleaner! Please do say, if there is anything else. Anders Johnsen On Saturday 26 April 2008 22:02:45 Gordon Henriksen wrote: > Hi Anders, > > Thanks for the patch.

I think you need to call "llvm::Function::deleteBody() first" On Tue, Mar 23, 2010 at 15:49, Reid Kleckner <rnk at mit.edu> wrote: > On Tue, Mar 23, 2010 at 7:04 AM, Gabi <bugspynet at gmail.com> wrote: >> Hi >> I get huge memory leaks using LLVM IRBuilder (trunk version) >> >> Basically I recreate a function over and over again, and pretty sure

On Fri, Apr 3, 2009 at 12:07 PM, Chris Lattner <clattner at apple.com> wrote: > It is impossible to tell with this amount of detail.  Does it work > correctly if you build with -O0 ? Yes, with -O0 the resulting executable looks fine. --enable-debug actually sets -O0 (otherwise -O2). Clang can build/test php 5.2.9 with either -O0 or -O2, but not for php 5.3RC0 with -O2. I further

What version of clang are you using? It could be a regression between head and the version I used. (some days old) - Anders On Fri, Apr 3, 2009 at 6:37 PM, Xi Wang <xi.wang at gmail.com> wrote: > On Fri, Apr 3, 2009 at 12:07 PM, Chris Lattner <clattner at apple.com> wrote: >> It is impossible to tell with this amount of detail.  Does it work >> correctly if you build

Hi, I downloaded the file here, and used the same commands. This is what I got: Number of tests : 9537 5371 Tests skipped : 4166 ( 43.7%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 7 ( 0.1%) ( 0.1%) Expected fail : 3 ( 0.0%) ( 0.1%) Tests passed : 5361 ( 56.2%) ( 99.8%) I'm on linux x86_64 with clang version: "clang version 1.0

Hi, I was trying to build php using LLVM/Clang (trunk) on Mac OS X, 10.5.6. http://downloads.php.net/johannes/php-5.3.0RC1.tar.bz2 Apple gcc works. Clang generates a buggy executable. under php source root, CC=clang ./configure --disable-all make make test The resulting `php' will crash, even with an empty php file. Argument strings on the stack at: c0000000 ./sapi/cli/php #0

Hi.. Updated so you now set alignment through LLVMInstrSetAlignment. Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7420 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/cb72b4bb/attachment.patch>

Hi there, I'm writing an R extension that has a C component that relies on two third party libraries that I'm bundling with the extension. I'd like to statically link my resulting extension so that I can rely on the bundled versions of the libraries I'm distributing, so there's two questions - 1, does R allow statically linked C extensions to be used at runtime? 2, are there

This is important to Debian users -- packets exists only for testing and unstable version of Debian Linux.

I have Googled around looking for the magic configure to waf incantation to get this accomplished but nothing seems to work. Does anyone know how to build rpcclient statically linked? Or all binaries statically linked? Thanks! -aps

Hi all, I was running some tests cross-compiling and natively compiling for windows with mingw and found something strange: when I try to built flac statically linked and libogg is available as a dll, flac will use the dll instead of linking statically. If I built libogg with --disable-shared, flac will use the static library. This is the case for building natively as well as when

On 3 Sep 2017, at 02:41, Will Dietz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I can speculate the reasons from a technical standpoint and by > inferring from commit history... > but curious if there's a better answer to be had? There’s a fairly noticeably performance improvement from static linking. I think last time I benchmarked it, building FreeBSD with

Sincere question! I'm not at all suggesting this is the wrong choice or asking it to be defended, just explained :) Simply curious if anyone can speak as to the reasons for this and perhaps give a sense of how strong these reasons are or if they're just the tie-breaking reasons we came up with because hosting /both/ seemed silly :P. (or whatever the case may be) I'll note the build