similar to: [LLVMdev] making libraries depend on external libraries?

I have an issue with the OCaml build system and the ExecutionEngine. PR2128 has a patch to change the Interpreter to use libffi. This breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't try to link with libffi, even though llvm-config knows that we should: $ Debug/bin/llvm-config --ldflags interpreter -L/home/nicholas/llvm-commit/Debug/lib -lpthread -lffi -ldl -lm

On 2009-01-19, at 13:50, Nick Lewycky wrote: > I have an issue with the OCaml build system and the ExecutionEngine. > > PR2128 has a patch to change the Interpreter to use libffi. This > breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't > try to link with libffi, even though llvm-config knows that we should: > > $ Debug/bin/llvm-config --ldflags

I have been working successfully with llvm-gcc for some time now with support for c/c++. Today I tried going back and reconfiguring and rebuilding with support for fortran, and I am running into problems. It seems ld cannot find -lffi. I am configuring like this: /gro/pkg/src/llvm-gcc/configure --prefix=/pkg/bin/llvm-gcc --program-prefix=llvm- --enable-llvm=/pkg/build/llvm

[Resending as my previous message was sent to moderation. The list info page doesn't mention this is a subscriber only list] I'm trying to write a .so which will be loaded using dlopen and called using dlopen. The application is written in C and I want to use the LLVM C API jfrom it. Obviously it will end up calling C++ functions internally but as long as I expose a C API to the

>> Daniel's comments are also good. > > …success! Looks like I spoke a bit too soon. Everything works as far as the fat binaries are concerned, except that -mmacosx-version-min is set to the host’s OS version, not that of the SDK, causing errors when it tries to link against 10.6’s versions of libraries instead of 10.5’s. This patch appears to solve that; it uses the OS version

Checking out LLVM from svn and building, I get: llvm[2]: Linking Release executable ModuleMaker (without symbols) /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_fr ame_hdr table will be created. /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); n o .eh_frame_hdr table will be created. /usr/bin/ld: error in

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

Reid added some nice inter-library dependency data to utils/llvm- config/LibDeps.txt. There are three sets of circular dependencies between LLVM libraries. If you use any library from one of these sets, you may need to pull in the rest: LLVMCodeGen.o LLVMSelectionDAG.o libLLVMAnalysis.a libLLVMTarget.a libLLVMTransformUtils.a libLLVMipa.a LLVMSparcV9.o LLVMSparcV9InstrSched.o

I've run into a problem with the ocaml bindings and the jit. It builds fine without the jit, but when I try to include it it tries to use the c object files from the build location, instead of the install location: > llvm-config --libdir --libfiles engine /opt/local/lib /opt/local/lib/LLVMX86.o /opt/local/lib/libLLVMSelectionDAG.a /opt/local/lib/libLLVMCodeGen.a

Simon Burton <simon at arrowtheory.com> writes: >> There are several possibilities here: either add1 is assigned a NULL >> pointer, or LLVM was unable to use the JIT and generates bytecode >> instead of native code, or invalid native code was generated >> (unlikely). > > Well, it's not NULL: > > (gdb) print add1 > $1 = (int (*)(int)) 0x83e43b8 >

Hi Andrew, > Checking out LLVM from svn and building, I get: > > llvm[2]: Linking Release executable ModuleMaker (without symbols) > /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_fr > ame_hdr table will be created. > /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); n > o .eh_frame_hdr table will be created. >

Hello there, I am trying to compile llvm from git the gentoo ebuild llvm-9999.ebuild. Recently I get an error during compilation. I am using gcc 4.9.0. The error is the following: x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -fomit-frame-pointer -march=native -O2 -pipe -fomit-frame-pointer -march=native -O2 -pipe -fomit-frame-pointer -march=native -O2 -pipe -fomit-frame-pointer -march=native

Hi Eric, Its definitely amusing :) About the only thing I can suggest are: 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already happening with the new Sparc backend that is being developed. Should be out in 1.7 (Chris?) 2. Combine the JIT/Interpreter/ExecutionEngine into one .a I don't know enough about the codegen/target/analysis/ipa stuff to be able to make any

On Thu, 13 Apr 2006 18:07:42 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: > > Simon Burton <simon at arrowtheory.com> writes: > > > I'm trying to take assembly and create machine code I can execute. > > How close am I ? > > Your test case is not complete. Besides, which version of llvm are you > using? What are the commands for compiling

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT

My 7 zip file manager says that the mingw binary is corrupt for llvm 1.9. I suppose that means that those of us running windows have no hope of getting llvm right now? Someone reported this earlier but the situation remains unchanged. -Matt

On Tue, May 4, 2010 at 5:31 PM, Yuri <yuri at tsoft.com> wrote: > Jeffrey Yasskin wrote: >>> >>> Would you try the patch at >>> http://codereview.appspot.com/download/issue968046_1.diff? It should >>> make the BSDs fall into the same path as Linux, and since you use gnu >>> ld, that should work for you. >>> >> >> Ping?

Duncan Sands wrote: > Hi Nathan, > > >> The latter being what GenLibDeps.pl expects to see. All else being >> equal though, it might be better to change GenLibDeps.pl to recognize >> the first version: >> --- GenLibDeps.pl (revision 78653) >> +++ GenLibDeps.pl (working copy) >> @@ -100,7 +100,7 @@ >> print "

Hi Nathan, > The latter being what GenLibDeps.pl expects to see. All else being > equal though, it might be better to change GenLibDeps.pl to recognize > the first version: > --- GenLibDeps.pl (revision 78653) > +++ GenLibDeps.pl (working copy) > @@ -100,7 +100,7 @@ > print " <dt><b>$lib</b</dt><dd><ul>\n";

On Tue, 21 Mar 2006, Reid Spencer wrote: > About the only thing I can suggest are: > > 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already > happening with the new Sparc backend that is being developed. Should be > out in 1.7 (Chris?) I wouldn't worry about the SparcV9 backend for your project. > 2. Combine the JIT/Interpreter/ExecutionEngine into one .a