Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Building 64-bit libraries on OS X"
2009 Feb 10
0
[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
2009 Feb 09
1
[LLVMdev] Building 64-bit libraries on OS X
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
2009 Feb 16
1
[LLVMdev] Invalid call generated on 64-bit linux when calling native C function from IR
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
2009 May 08
2
[LLVMdev] Darwin option processing
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
2009 May 08
2
[LLVMdev] Darwin option processing
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)
2018 Oct 02
2
R grpc
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
2008 Oct 02
1
acts_as_taggable_on environment issues
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
2007 Jun 13
5
[LLVMdev] How to call native functions from bytecode run in JIT?
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
2015 Sep 04
5
RFC: LTO should use -disable-llvm-verifier
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:
> >>>
> >>>
>
2016 Sep 30
7
libLTO C API stability policy
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
2009 Dec 04
4
[LLVMdev] Transparent LTO on Mac OS X
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
2015 Sep 04
2
RFC: LTO should use -disable-llvm-verifier
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
2009 Dec 04
0
[LLVMdev] Transparent LTO on Mac OS X
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
2013 Nov 12
3
[LLVMdev] Best way to do a lto bootstrap on OS X
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
2015 Sep 04
2
RFC: LTO should use -disable-llvm-verifier
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 <
>>
2007 Jun 11
2
[LLVMdev] How to call native functions from bytecode run in JIT?
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
2007 Jun 12
3
[LLVMdev] How to call native functions from bytecode run in JIT?
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,
2008 Dec 23
2
[LLVMdev] ParseAssemblyString change of behaviour
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
2016 Apr 16
2
[TSAN] LLVM statistics and pass initialization trigger race detection
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
2013 Nov 12
0
[LLVMdev] Best way to do a lto bootstrap on OS X
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