search for: shared_library

I suspect my change adding --enable-shared broke you, since that configure option didn't exist before last week (r97119). SHARED_LIBRARY is not one of the variables you're supposed to be able to set on make's command line (http://llvm.org/docs/MakefileGuide.html#variables). What are you using it for? What happens if you remove it? On Tue, Mar 2, 2010 at 1:35 PM, James Williams <junk at giantblob.com> wrote: > Hi, &...

Hi, Until recently I've been building LLVM with SHARED_LIBRARY=1. However, sith current svn, build now fails with unresolved symbols building opt. I've done a clean checkout, configure and make so it's not down to any local changes I've made. I'm building with: ./configure --enable-assertions \ --enable-expensive-checks=no \ --enable-pic \ --e...

Hi, Thanks for getting back to me. I don't actually need opt dynamically linked but I do want shared libraries. If run make without "SHARED_LIBRARY=1" I don't appear to get any shared libraries built or installed. Is LLVM built as shared libraries supported? If so what's the correct build procedure? -- James On 2 March 2010 21:51, Jeffrey Yasskin <jyasskin at google.com> wrote: > I suspect my change adding --enable-sh...

On Tue, Mar 2, 2010 at 2:13 PM, James Williams <junk at giantblob.com> wrote: > Hi, > > Thanks for getting back to me. > > I don't actually need opt dynamically linked but I do want shared libraries. > If run make without "SHARED_LIBRARY=1" I don't appear to get any shared > libraries built or installed. > > Is LLVM built as shared libraries supported? If so what's the correct build > procedure? Configuring with --enable-shared should build a Release/lib/libLLVM-2.7svn.so that includes all of the LLVM libr...

...01s] of target "liblldb" does not exist. [ 1501s] This warning is for project developers. Use -Wno-dev to suppress it. [ 1501s] [ 1501s] CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): [ 1501s] "lldPasses" of type SHARED_LIBRARY [ 1501s] depends on "lldNative" (weak) [ 1501s] depends on "lldYAML" (weak) [ 1501s] "lldNative" of type SHARED_LIBRARY [ 1501s] depends on "lldYAML" (weak) [ 1501s] depends on "lldPasses" (weak) [ 1501s] "lldYAML" of t...

James Williams <junk at giantblob.com> writes: > I don't actually need opt dynamically linked but I do want shared > libraries. The cmake build should work: http://www.llvm.org/docs/CMake.html BUILD_SHARED_LIBS:BOOL Flag indicating is shared libraries will be built. Its default value is OFF. Shared libraries are not supported on Windows and not recommended in the other

.... Let me explain how I get to this point. To make simpler my explanation I took the "Hello World" pass provided in the directory llvm/lib/Transforms/Hello/Hello.cpp. I compiled Hello.cpp using the Makefile: > LEVEL=../../../.. > LIBRARYNAME=MyAnalysis > LOADABLE_MODULE=1 > SHARED_LIBRARY=1 > include $(LEVEL)/Makefile.common and then: clang test.c -c -emit-llvm -o test.bc opt -load /home/jorge/SvnReps/Systems/llvm/build/Debug+Asserts/lib/MyAnalysis.so -hello -stats test.bc > Hello: modulo > ===-------------------------------------------------------------------------===...

...to investigate, I then ran CMake on my debug build (that has dynamic linking to avoid re-linking of huge libraries during development cycle), and I got this: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "lldPasses" of type SHARED_LIBRARY depends on "lldNative" (weak) depends on "lldYAML" (weak) "lldNative" of type SHARED_LIBRARY depends on "lldYAML" (weak) depends on "lldPasses" (weak) "lldYAML" of type SHARED_LIBRARY depends on "lldNative&quot...

...b778d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7611000) /lib/ld-linux.so.2 (0xb78cf000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75e7000) So I guess, my problem is in LD.Flags ? >> LEVEL=../../../.. >> LIBRARYNAME=MyAnalysis >> LOADABLE_MODULE=1 >> SHARED_LIBRARY=1 >> include $(LEVEL)/Makefile.common >> >> # These two lines are new: >> CXX.Flags += -I/home/jorge/include -fexceptions -Wno-variadic-macros >> LD.Flags += -L/home/jorge/lib -lppl -lgmp >> Ciao, Duncan. >> >> > >> > Let me explain...

...> > To make simpler my explanation I took the "Hello World" pass provided > in the directory llvm/lib/Transforms/Hello/Hello.cpp. > > I compiled Hello.cpp using the Makefile: > >> LEVEL=../../../.. >> LIBRARYNAME=MyAnalysis >> LOADABLE_MODULE=1 >> SHARED_LIBRARY=1 >> include $(LEVEL)/Makefile.common > > and then: > > clang test.c -c -emit-llvm -o test.bc > opt -load /home/jorge/SvnReps/Systems/llvm/build/Debug+Asserts/lib/MyAnalysis.so -hello -stats test.bc > >> Hello: modulo >> ===---------------------------------------...

Hello, I have a question about how to set up a Makefile that generate a .so that I can load into opt without getting duplicate symbols. Here's what I have right now: LIBRARYNAME=previrt SHARED_LIBRARY=previrt LINK_COMPONENTS := transformUtils LINK_LIBS_IN_SHARED=1 include $(LEVEL)/Makefile.common LIBS += -lprotobuf CPPFLAGS += -I${HOME}/.root/usr/include -DGOOGLE_PROTOBUF_NO_RTTI LDFLAGS += -Wl,-L${HOME}/.root/usr/lib/ PROTOC=${HOME}/.root/usr/bin/protoc I'm pretty sure the problem comes...

...feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library intended for dynamic linking (i.e. system automated linking at runtime such as with ld.so) that *may* also be dlopenable on some systems, but isn't gauranteed to be openable. If you want to gaurantee that it can be dlopened then you must also specify LOADABLE_...

...ered it as optimization pass because it so nice documented and speeds up the compilation and testing times dramaticly :-). Then i just registered this part as an analysis part which should be used in a modified cbackend. All seems to work fine, exept that llc fails to link. I tried removing the SHARED_LIBRARY = 1 and LOADABLE_MODULE= 1 options from the Makefile since it should be included by default in my build. Then i tried to add the .a file to the llc makefile. But it didn't help either... :-( Any hints what's missing? Btw. there was a way to make the makefile run more verbose. It was doc...

...Fix your Makefile to build a shared library properly. You have set > TOOLNAME which is for building an executable tool not a shared > library. You need to set LIBRARYNAME=..., not TOOLNAME=... I remember having failed to build a functioning Python extension module with LIBRARYNAME and SHARED_LIBRARY flags. Anyway, I cannot remember the details now so will try again. > 4. Fix the name of your project. It currently builds "llvm.so" which > is not correct by our naming standards. It should result to something > like "libLLVMpy.so" which will be obtained if you...

...ally tried doing this in cygwin where I dont see the shared library being built. Do u think it could have been cygwin that is the problem? Aparna On Mon, Apr 13, 2009 at 5:16 PM, Milos Puzovic <milos.puzovic at gmail.com>wrote: > In order to generate shared libraries you need to have SHARED_LIBRARY > and LOADABLE_MODULE defined in the Makefile. See here for more > details: http://llvm.org/docs/MakefileGuide.html#libraries > > On 13 Apr 2009, at 20:46, aparna kotha wrote: > > > I am trying to run the LLVM hello world pass. I observe that in the > > OUPUT_DIR/lib the...

...39;m facing some problems while building LLVM 2.8 shared libraries from source using CMake: cmake -DBUILD_SHARED_LIBS=true .. This is the output error: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "LLVMARMCodeGen" of type SHARED_LIBRARY depends on "LLVMARMAsmPrinter" "LLVMARMAsmPrinter" of type SHARED_LIBRARY depends on "LLVMARMCodeGen" At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. Does anyone else had the same problem ?...

During my project, it was very slow when I linked my program with the static libraries vmcore, asmparser, and support.a. Then I tried to compile these LLVM modules as shared libraries, by set SHARED_LIBRARY = 1 for those makefiles. It did generate the *.so libraries. However, when I linked with the shared libraries, it always complained that ...llvm/lib/Debug/libsupport.so: undefined reference to `dlerror' ...llvm/lib/Debug/libsupport.so: undefined reference to `dlopen' ...llvm/lib/Debug/lib...

hello... I have finish my backend. But I dont know how to install my backend... llc -load=???Load what?? Can anyone teach me? thanx.

...an anyone teach me? > thanx. There are two ways to do this. You can either link the backend directly into llc (like the X86 or PowerPC backends, see tools/llc/Makefile), or you can dynamically load the backend. To dynamically load the back end, add these two lines to your target makefile: SHARED_LIBRARY = 1 LOADABLE_MODULE = 1 This should build a DSO for your target (which will end with .so if you're on most unixy platforms). You can load this with: llc --load ~/llvm/Debug/lib/yourlibrary.so -march=yourarch in.bc -o out.s BTW, what architecture are you working with? -Chris -- http:/...

...;<j->getName()<<" "<<InstructionList.size()<<endl; ...... ...... } RegisterPass<MParSchedule> X("MParSchedule","MParSchedule"); ------------------------ Makefile MParschedule LEVEL = ../../../.. LIBRARYNAME= MParSchedule BUILD_ARCHIVE=1 SHARED_LIBRARY = 1 LOADABLE_MODULE= 1 include $(LEVEL)/Makefile.common ------------------------- Makefile MyBackend LEVEL = ../../.. LIBRARYNAME = MyBackend PARALLEL_DIRS = MParSchedule USEDLIBS = MParSchedule.o LLVMLIBS = LLVMCore.a LLVMSupport.a LLVMSystem.a MParSchedule.a #LIBS += -lMParSchedule #LINK_COMPONE...