similar to: [LLVMdev] Building 64-bit libraries on OS X

To build 64-bit libraries (i.e. 'file <library>' shows x86_64) try 'make EXTRA_OPTIONS=-m64" Either 32-bit or 64-bit libraries are able to generate code for either 32-bit or 64-bit, try -m32 or -m64 at runtime On Feb 9, 2009, at 4:16 PMPST, Jan Rehders wrote: > Hi, > > how do I compile LLVM for 64-bit on OS X? I want to get 64-bit > libraries which

Hi, how do I compile LLVM for 64-bit on OS X? I want to get 64-bit libraries which generate x86_64 to link them into a 64-bit application. All my attempts ended up with either 32-bit libraries or errors. My machine is an Intel Xeon quad core, 'sysctl hw.cpu64bit_capable' returns 1 so I think the machine is fine. - './configure && make' yields 32-bit libraries and

Hi, when I try to generate LLVM-IR which calls back to native C functions the jit compiler generates invalid code on 64-bit linux. The same code works fine on 32-bit linux, 32-bit OS X and 64-bit OS X. A reproduction case is attached to this mail. It is a simple modification of the "How to use jit" example adding a call to a native function. I am currently using EE->addGlobalMapping

On May 8, 2009, at 11:49 AM, Chris Lattner wrote: > On May 7, 2009, at 6:24 PM, Mike Stump wrote: >> I'm toying with building with -mdynamic-no-pic, but for this to work, >> the shared library bits in llvm can't be built with that flag. > > Hi Mike, > > If you're doing this for Clang's benefit, No, not really, I'm doing it for the general benefit of

I'm toying with building with -mdynamic-no-pic, but for this to work, the shared library bits in llvm can't be built with that flag. I've found that: Index: Makefile.rules =================================================================== --- Makefile.rules (revision 71041) +++ Makefile.rules (working copy) @@ -472,6 +476,9 @@ ifneq ($(DARWIN_MAJVERS),4) LD.Flags += $(RPATH)

Hello, I am looking for a prebuild - binary MS Windows version of the R grpc package https://github.com/nfultz/grpc best regards Witek -- Witold Eryk Wolski

Like most people, I''ve got two machines: one for development and one for production. I''ve done everything I can to make sure the ruby/rails environments are the same, but of course they''re not identical (I''ll get into that in a moment). The error that I''m getting happens when I call a method in a background task controller on the production machine; I

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

On Fri, Sep 04, 2015 at 03:11:39PM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:38 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > >> > >>> On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > >>> > >>> >

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

Are you building llvm-gcc yourself? If so, what version? Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. If you are only using llvm-gcc from the Xcode tools release, use the driver from: /Developer/usr/bin/llvm-gcc-4.2 If you are building llvm-gcc yourself, try, in this order: 1) sudo ln -s

On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo

Shantonu Sen wrote: > Are you building llvm-gcc yourself? If so, what version? > > Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. > Thanks. A bitcode format mismatch was the problem. I'm not sure if the problem stems from the fact that the bitcode was generated for the wrong architecture

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > >> Hi, >> >> > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < >>

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

On Tue, 12 Jun 2007, Jan Rehders wrote: >> Jan, how are you doing this? Are you creating an external LLVM >> Function object named "get5", then using EE::addGlobalMapping? If >> 'get5' exists in the address space, why not just let the JIT resolve it >> (which will then create the stub)? > > Yes. I create a Function with matching signature,

Hi, when upgrading my compiler from LLVM 2.1 to 2.4 I stumbled upon a change of behaviour in ParseAssemblyString. For an interactive toplevel I am generating .ll source and feeding it into ParseAssemblyString like this: Module* parsedModule = ParseAssemblyString( code, targetModule, &errorInfo ); where targetModule is the module I expect all the LLVM code to go. Until 2.1 the

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this