similar to: [LLVMdev] building clang when present

On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: > In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. > It may require some changes to ‘Makefile.rules’ to work as > intended, though. If there's interest in such a change, I can prepare > a patch? Are OPTIONAL_DIRS parallel? For some reason, I was assuming not.

On 19 Jan 2009, at 19:08, Mike Stump wrote: > This patch eases building clang when present in the source tree. > Since clang is revlocked to llvm, one usually updates them together, > and builds them together. > > Ok? In my humble opinion, using OPTIONAL_DIRS would be better and cleaner. It may require some changes to ‘Makefile.rules’ to work as intended, though. If

On Jan 19, 2009, at 12:35 PM, Dan Villiom Podlaski Christiansen wrote: > On 19 Jan 2009, at 21:16, Mike Stump wrote: > >> On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen >> wrote: >>> In my humble opinion, using OPTIONAL_DIRS would be better and >>> cleaner. >>> It may require some changes to ‘Makefile.rules’ to work as >>>

On 19 Jan 2009, at 21:16, Mike Stump wrote: > On Jan 19, 2009, at 11:55 AM, Dan Villiom Podlaski Christiansen wrote: >> In my humble opinion, using OPTIONAL_DIRS would be better and >> cleaner. >> It may require some changes to ‘Makefile.rules’ to work as >> intended, though. If there's interest in such a change, I can prepare >> a patch? > > Are

On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote: > On Jan 19, 2009, at 10:02 AM, Mike Stump wrote: > >> There isn't a good reason to create files called .dir in the >> installation directory. This patch fixes that. > > If we don't have this line, every build with do the makedir. And? $ time mkdir -p /bin real 0m0.002s user 0m0.000s sys 0m0.002s an extra mkdir

Hello, Tatu > Is that correct? I think it's just something to be aware of. Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov

On Oct 17, 2008, at 7:30 AM, Anton Korobeynikov wrote: > Hello, Tatu > >> Is that correct? I think it's just something to be aware of. > Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior? Please no flag. If we want to fix this problem, lets do it right. To me this

Oscar, I be willing to donate some machine time to you. How about a 2 x 3GHz Dual Core Intel Xeon with 8GB? The question is how to get past the NAT. Email me privately if interested. Regards Mark Kromis On Nov 11, 2008, at 12:12 AM, Óscar Fuentes wrote: > Reports arrived indicating that the LLVM cmake-based build system is > lacking some OS X specific work, which seems to be the OS of

Hi, > gcc: gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) most likely the version of gcc you are using is broken. See http://llvm.org/docs/GettingStarted.html#brokengcc Ciao, Duncan.

Hi, I am just starting a new project. I found that the above script rejects Autoconf versions later than 2.59, whereas it ought to accept them, imho. I had to edit the scrip to be able to use it with Autoconf 2.61. Also, aclocal gave the following warning: /usr/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF /usr/share/aclocal/oaf.m4:4: run info '(automake)Extending

Reports arrived indicating that the LLVM cmake-based build system is lacking some OS X specific work, which seems to be the OS of choice for quite a few LLVM developers. I know there are sites out there that offer Linux shell accounts. Is there something similar for OS X, where building LLVM would be possible? A google search turned no solid results. Or would someone donate ssh access and approx.

Hi, When i wanted to build the llvm-gcc, i got the problem as following. ========================================================================================================================== cc1: /home/cllou/LLVM/llvm-2.4-dir/llvm-2.4/lib/Support/StringMap.cpp:177: void llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*): Assertion `V == V2 && "Didn't find

It seems that --enable-shared builds are not used by LLVM developers because the executables starts slowly. I guess this is related to the number of symbols the dynamic linker has to resolve. If we could reduce the symbols exported to those which are required, maybe the startup time would become bearable. One way of doing this is to add annotations to each public class and function (such as

Hi all, I've previously posted this patch on llvm-commits, but due to a lack of replies, and the fact that this patch is more something to discuss than something to apply, I'm posting this again here. While working on my own backend, I found that things got really messy real quickly, partly caused by the fact that all .cpp files must be in the same directory (lib/Target/TargetName).

2009/1/2 Chris Lattner <clattner at apple.com> > On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote: > Do you have a specific example of a unit test that would need these? I > really think these should stay private. > Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the high-level

Óscar Fuentes wrote: > It seems that --enable-shared builds are not used by LLVM developers > because the executables starts slowly. I guess this is related to the > number of symbols the dynamic linker has to resolve. If we could reduce > the symbols exported to those which are required, maybe the startup time > would become bearable. I think that premise needs to be retested. I

On 20 Jan 2009, at 00:04, Mike Stump wrote: > On Jan 19, 2009, at 1:58 PM, Chris Lattner wrote: >> On Jan 19, 2009, at 10:02 AM, Mike Stump wrote: >> >>> There isn't a good reason to create files called .dir in the >>> installation directory. This patch fixes that. >> >> If we don't have this line, every build with do the makedir. > >

Hello all, I have replaced the llvm-gcc shipped with the Xcode by the latest version and I was wondering if I have missed something... (everything *seems* to work). Here's what I did: 0. Checkout LLVM (and clang) + llvm-gcc 1. Build LLVM (with clang) and install into /Developer/usr/local : # mkdir llvmobj # cd llvmobj # CC=gcc-4.2 CXX=g++-4.2 ../llvm/configure

On Nov 12, 2009, at 11:43 AM, John Criswell wrote: > Dear LLVMers, > > I'm currently working on creating an alternate libLTO.so that will run > some whole-program analysis and transforms of mine during the final > linking of an executable. The idea is for it to link all of the > bitcode > files together, run the regular LTO passes, and then run my passes. > For

On Dec 4, 2009, at 2:49 PM, John Criswell wrote: >> If you are building llvm-gcc yourself, try, in this order: >> 1) sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/ >> libLTO.dylib >> >> 2) If you still get errors, try installing the libLTO.dylib from >> your LLVM build into /Developer/usr/lib. Make sure that if you're >> on a 64-bit