similar to: [LLVMdev] UPDATE: Makefile.rules Changes (IMPORTANT)

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

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

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

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

Hello, I've closed PR106 (use automake) as WONTFIX. I've already delineated the problems with automake in previous posts but as of now, all the automake related stuff has been removed from the repository. In an effort to start making our makefile system better, I've committed changes to Makefile.rules and a few library Makefiles that nearly double the speed of our compilations. I

My final foray into the makefiles for a while has been completed. The dist-check target is the golden nugget I was hoping to get out of automake. But, now LLVM Makefiles have it too. dist-check does the following: * builds everything with "check" to ensure the source of the distribution is sane, essentially "make check". * builds the distribution tar balls with

Hi Reid, just a quick note while you're doing this, a while ago I ran into a problem that the standard makefiles weren't building libraries (like, say, a new pass) correctly on OS X - they were being built as shared libraries and not bundles, so they couldn't be loaded with dlopen. The discussion is in the archives if you want more details... I fixed it locally by doing the following

Hi, In buildling XPS using LLVM's makefile system, I'm finding that there's a few things lacking in our support for LLVM-based projects. The items below should help but may require changes to project makefiles. I thought I'd check before just going and doing it. 1. Various autoconf generated variables (e.g. abs_top_srcdir) are set in the makefiles but not used. They

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements

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

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements for projects.

The llvm.cs.uiuc.edu site does not seem to be updating at the moment so it contains the old instructions. If you're looking for the new instructions on the Projects.html page, you can view them here: http://illuvium.net/docs/Projects.html Reid. On Sat, 2005-01-15 at 18:30, Reid Spencer wrote: > The proposed makefile changes have been committed. If you are working > from CVS head and

Michael, I've implemented a LOADABLE_MODULE 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

yue wrote: > hi, > about [LLVMdev] another question > > thanks > > yueqiang One other thing you might want to try is to put your object tree in a directory that is *not* inside of your source tree. Currently, we don't support using separate object trees that are subdirectories of the source tree. In other words: Will work: ========== SRC_ROOT=/home/yue/llvm

Hi John, I have attached my Makefile.config. I noticed that I did'nt have SRC_ROOT and OBJ_ROOT variables defined as such in my environment. But I noticed that this is defined in the Makefile.config by default to the same values. All the same, I tried defining both these variables in my .cshrc, but I still get the same error. The main directory for me is /home/llvm, and I have

The opus code default compiles on -o2 optimization level. I would like to change it to -o3. I have tried doing the changes in makefile.unix . The change is not getting reflected. I am building the code in Code composer studio for TI processor C6000. Could anybody help me with this -------------- next part -------------- An HTML attachment was scrubbed... URL:

Anybody having success building an LLVM.dll in this configuration? It's failing for me, in tools/llvm-shlib, with an error suggesting that the gcc ld doesn't understand the format of the exports map being generated. (plain configure && make works just fine, it's just this shared option that fails; google shows support for --enable-shared was added around 2.7 timeframe and

Good midnight, Kevin. cygming/shared might have been broken since r112976, IIRC. (ToT, too) A trivial patch; --- a/Makefile.rules +++ b/Makefile.rules @@ -942,6 +942,11 @@ ifdef EXPORTED_SYMBOL_FILE # First, set up the native export file, which may differ from the source # export file. +# The option --version-script is not effective on GNU ld win32. +ifneq (,$(filter $(HOST_OS),Cygwin

On Fri, 14 Jan 2005, Reid Spencer wrote: > In buildling XPS using LLVM's makefile system, I'm finding that there's > a few things lacking in our support for LLVM-based projects. The items > below should help but may require changes to project makefiles. I > thought I'd check before just going and doing it. ok. > 1. Various autoconf generated variables (e.g.