similar to: [LLVMdev] building clang when present

Displaying 20 results from an estimated 1100 matches similar to: "[LLVMdev] building clang when present"

2009 Jan 19
2
[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.
2009 Jan 19
0
[LLVMdev] building clang when present
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
2009 Jan 19
3
[LLVMdev] building clang when present
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 >>>
2009 Jan 19
0
[LLVMdev] building clang when present
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
2009 Jan 19
3
[LLVMdev] avoid creating .dir files
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
2008 Oct 17
3
[LLVMdev] merging globals
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
2008 Oct 17
0
[LLVMdev] merging globals
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
2008 Nov 11
0
[LLVMdev] A shell account on a OS X machine?
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
2008 Dec 13
0
[LLVMdev] internal compiler error problem in build llvm-gcc
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.
2008 Dec 17
2
[LLVMdev] AutoRegen.sh bug
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
2008 Nov 11
2
[LLVMdev] A shell account on a OS X machine?
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.
2008 Dec 13
2
[LLVMdev] internal compiler error problem in build llvm-gcc
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
2008 Nov 12
7
[LLVMdev] Practical --enable-shared LLVM builds.
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
2008 Dec 01
3
[LLVMdev] Multiple directories in a single library
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 Jan 02
3
[LLVMdev] Private headers and testing
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
2008 Nov 13
0
[LLVMdev] Practical --enable-shared LLVM builds.
Ó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
2009 Jan 20
0
[LLVMdev] avoid creating .dir files
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. > >
2008 Oct 21
4
[LLVMdev] Replacing llvm-gcc in Xcode 3.1.1 with svn version
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
2009 Nov 12
0
[LLVMdev] libLTO on Mac OS X
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
2009 Dec 04
1
[LLVMdev] Transparent LTO on Mac OS X
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