search for: llvmusedlibs

...IBRARY +ifneq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) ifneq ($(HOST_OS),Darwin) LD.Flags += $(RPATH) -Wl,'$$ORIGIN' else ifneq ($(DARWIN_MAJVERS),4) - LD.Flags += $(RPATH) -Wl,$(LibDir) + LD.Flags += $(RPATH) -Wl,$(SharedDir) +endif endif endif endif @@ -960,6 +976,13 @@ LLVMUsedLibs := $(patsubst %.a.o, lib%.a, $(addsuffix .o, $(LLVMLIBS))) LLVMLibsPaths := $(addprefix $(LLVMLibDir)/,$(LLVMUsedLibs)) endif +# Win32.DLL may refer to other components. +ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) + ifdef LOADABLE_MODULE + LINK_COMPONENTS := all + endif +en...

...LLVMToolDirSlash. This seems like a gratuitous change to me. 2. I don't think the change to CPP.Flags is right. It won't find the LLVM header files 3. Removing the .PRECIOUS line will interfere with correct operation of parallel (make -j N) builds. 4. I don't understand why LLVMUsedLibs and other variables should only be set if LLVMLibDir is defined. Before this change is committed, you need to test that all our scenarios, in each combination: 1. Both with and without OBJ_DIR == SRC_DIR 2. Single and Parallel builds 3. Building LLVM versus building a project (and now buildi...

...rs. --ldflags Linker flags. --libs <COMPONENT>... Libraries needed to link against LLVM components. Right now, the only useful component is the JIT: jit LLVM JIT compiler. I get this set of dependencies using: LLVMLIBS := JIT SUB_JITOBJS=$(LLVMUsedLibs) It's very easy to dump a Makefile variable to the llvm-config script, so the only obstacle to adding more configurations is modularizing the code which processes LLVMLIBS. > I would be quite happy to have a hard-coded list of library > dependencies, even if it means that we need...

>> Patch attached. >> >> This patch with header installation patch ( >> http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html ) >> let external project (I am test it at my YAFL frontend for LLVM) build >> using installed LLVM version instead using LLVM obj/src dirs. > > I think the patch looks basically sane. The one wierd thing I notice

...was pretty > much it. Thanks for your advice! I did get everything working (eventually) by pasting the following code into the Makefile for HowToUseJIT: .PHONY: dump-config dump-config: @echo Compile: $(Compile.CXX) @echo Link: $(Link) @echo Libs: $(LLVMUsedLibs) ...and using the result. But this is still pretty fragile, and needs be done once for every supported platform. Gnome (and many other Unix projects with massively ugly dependencies) can be linked trivially using a "foo-config" script. If LLVM had something similar, it might save...

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

...ARY +ifneq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) ifneq ($(HOST_OS),Darwin) LD.Flags += $(RPATH) -Wl,'$$ORIGIN' else ifneq ($(DARWIN_MAJVERS),4) - LD.Flags += $(RPATH) -Wl,$(LibDir) + LD.Flags += $(RPATH) -Wl,$(SharedLibDir) +endif endif endif endif @@ -960,6 +977,13 @@ LLVMUsedLibs := $(patsubst %.a.o, lib%.a, $(addsuffix .o, $(LLVMLIBS))) LLVMLibsPaths := $(addprefix $(LLVMLibDir)/,$(LLVMUsedLibs)) endif +# Win32.DLL may refer to other components. +ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW)) + ifdef LOADABLE_MODULE + LINK_COMPONENTS := all + endif +en...

> 1) The only supported way to link against LLVM from outside the build > directory is to use Makefile.common and the LLVM build system, both of > which require an LLVM build tree. Without extensive customization: > a) I can't link against the installed LLVM libraries and headers. > b) I can't use my projects' pre-existing build systems (automake, > rake, or

On Wed, 15 Mar 2006, Eric Kidd wrote: > On Mar 14, 2006, at 2:22 PM, Chris Lattner wrote: >>> Gnome (and many other Unix projects with massively ugly dependencies) can >>> be linked trivially using a "foo-config" script. If LLVM had something >>> similar, it might save new LLVM developers several hours of digging >>> through manuals and

...st patch with parallel builds. Related question lines: -LLVMExmplDir:= $(LLVM_OBJ_ROOT)/$(BuildMode)/examples and -.PRECIOUS: $(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir Is removing LLVMExmplDir definition is ok? It not used anywhere in LLVM CVS > 4. I don't understand why LLVMUsedLibs and other variables should only be > set if LLVMLibDir is defined. I don link strange filenames if LLVMLibDir will not define and project tooldir/Makefile set LLVMLIBS. But i will skip this part of changes in next version of patch. > Before this change is committed, you need to test that...

...t; Thanks for your advice! I did get everything working (eventually) by pasting > the following code into the Makefile for HowToUseJIT: > > .PHONY: dump-config > dump-config: > @echo Compile: $(Compile.CXX) > @echo Link: $(Link) > @echo Libs: $(LLVMUsedLibs) > > ...and using the result. But this is still pretty fragile, and needs be done > once for every supported platform. Ok. This is a reasonable way to do it. FWIW, I have a similar problem in the new llvm-gcc, which links to LLVM optimizations and native targets. The makefile goop I...

On Mar 14, 2006, at 2:22 PM, Chris Lattner wrote: >> Gnome (and many other Unix projects with massively ugly >> dependencies) can be linked trivially using a "foo-config" script. >> If LLVM had something similar, it might save new LLVM developers >> several hours of digging through manuals and Makefiles. > > This would be very very cool to have. OK!

Hello! I'm considering using LLVM for several different projects in the future, so I'm conducting a technical evaluation. So far, the APIs and the benchmark results look absolutely great. Things I really like: 1) LLVM is low-level enough to support most languages that run on standard hardware. 2) The JIT examples are really straightforward. 3) The documentation is remarkably good. 4)

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron