similar to: [LLVMdev] Building the shared library on Mac OS X

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

On Mon, Nov 11, 2013 at 01:59:25PM +0400, Alexander Potapenko wrote: > Jack, > > Where do the "-isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk > -mmacosx-version-min=10.8" flags come from? I don't see them in your > CMake invocation - perhaps they're added via $CC or $CFLAGS? Is this > being done

On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > This file is for configure+make build, not CMake, so I'm not sure why > it's being included into your build (these failures aren't > reproducible for me). > Can you please list the exact steps you're doing to build LLVM with > CMake and make sure you don't have additional CFLAGS (LDFLAGS etc)

+Bob Wilson I don't know if this is a recent Apple regression, or if it's now catching something which had always been invalid. -bw On Mon, Nov 11, 2013 at 8:44 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Mon, Nov 11, 2013 at 11:03:47AM -0500, Jack Howarth wrote: > > On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > > > This

This file is for configure+make build, not CMake, so I'm not sure why it's being included into your build (these failures aren't reproducible for me). Can you please list the exact steps you're doing to build LLVM with CMake and make sure you don't have additional CFLAGS (LDFLAGS etc) defined? On Mon, Nov 11, 2013 at 6:16 PM, Jack Howarth <howarth at bromo.med.uc.edu>

On Mon, Nov 11, 2013 at 11:03:47AM -0500, Jack Howarth wrote: > On Mon, Nov 11, 2013 at 06:46:47PM +0400, Alexander Potapenko wrote: > > This file is for configure+make build, not CMake, so I'm not sure why > > it's being included into your build (these failures aren't > > reproducible for me). > > Can you please list the exact steps you're doing to build

Hi, We are embedding our DSL language + LLVM in a modified WebKit based Safari on OSX. Starting with LLVM 3.3 (it was working with LLVM 3.1...) we see the following crash: Any idea? Thanks. Stéphane Letz ====================== Process: SafariForWebKitDevelopment [79228] Path: /Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment Identifier:

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Jack, Where do the "-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8" flags come from? I don't see them in your CMake invocation - perhaps they're added via $CC or $CFLAGS? Is this being done on purpose? I can add a CMake step checking whether the current CFLAGS/LDFLAGS allow to build an

Hello Dmitry, First of all, thank you for your reply. Because of it, I focused in create the lib that helped me. Second, I realize that actually there was one thing different between the machines: due to a more frequent use of the iMac, I have a group of environment variables that are set to my developer folder; and the $PATH is one of those. Furthermore, it seems that my default compiler for

On Mon, Oct 22, 2012 at 10:17:56AM -0700, Nick Kledzik wrote: > Jack, > > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image

On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote: > I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. > > There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at

On Tue, Oct 23, 2012 at 09:41:46AM +0200, Duncan Sands wrote: > Hi, > >> I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: >> >> dyld: fast lazy bind offset out of range (53437, max=7640) in image

Hi, > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 > > means the initializer

Hi, I'm trying to use llvm/clang to cross compile to sparcv9. The following works with a -march=sparc, but yields errors for sparcv9. Are there some other flags that need to be specified? Thanks, Tarun > clang -m64 -emit-llvm test.c -c -o test.bc > llc -march=sparcv9 test.bc -o hello.s ExpandIntegerResult #0: 0x8a6c478: i64 = GlobalAddress<[4 x i8]* @.str> 0 [ORD=1] [ID=0] Do

Using Valgrind hasn't shown me anything terribly unusual. And I'm confused because its not even trying to delete a real instruction; deleting a void type with no name? That doesn't make any sense... Any other hints? I've seen a few posts in the past about this relating to some internal LLVM bugs... -Griffin On Thu, 12 Jan 2012 21:26:41 +0100, Duncan Sands <baldrick at

Hi Griffin, did your pass create a data structure that holds values somehow, and forgot to delete it? Also, try running under valgrind in case this is due to a memory error of some kind. Ciao, Duncan. > So I have an LLVM pass that appears to run completely and work fine, and > then it aborts at the very end. When exiting the final runOnFunction call, > I get the following error /

On 12/12/11 9:59 AM, neda 8664 wrote: > hi all, > > I want access to all basic blocks of function in a loop, so I used the > following code: > > /bool parallel::runOnLoop(Loop *L, LPPassManager &LPM) > { > for (Function::iterator bi= func->begin(); bi != func->end(); bi++){ > // > } > }/ Are you modifying anything within this code

Hey everyone, So I have an LLVM pass that appears to run completely and work fine, and then it aborts at the very end. When exiting the final runOnFunction call, I get the following error / stack dump. I cannot figure out why this is happening for the life of me - does anyone have any ideas? I'm not trying to do any crazy deallocation or anything, it just seems like a normal pass to me.