search for: cc_for_target

...n't been a terrible problem for Google, but I > do think it is something that should be fixed (I'm working on another > aspect of compiler-rt bringup at the moment, so won't solve this in the > immediate future.) > Rightio > > gnu systems have a make variable, "CC_FOR_TARGET" that addresses this > problem. I imagine llvm should adopt a similar mechanism inside cmake. > Not sure I follow on the need/use of CC_FOR_TARGET compared to using the just-built clang as the CC_FOR_TARGET (which it seems we have some plumbing for already - the just-built clang is used...

...rrible problem for Google, but I > do think it is something that should be fixed (I'm working on another > aspect of compiler-rt bringup at the moment, so won't solve this in the > immediate future.) > > > Rightio > > > > gnu systems have a make variable, "CC_FOR_TARGET" that addresses this > problem. I imagine llvm should adopt a similar mechanism inside cmake. > > > Not sure I follow on the need/use of CC_FOR_TARGET compared to using the > just-built clang as the CC_FOR_TARGET (which it seems we have some plumbing > for already - the just-...

...o think it is something that should be fixed (I'm >> working on another aspect of compiler-rt bringup at the moment, >> so won't solve this in the immediate future.) >> >> >> Rightio >> >> >> gnu systems have a make variable, "CC_FOR_TARGET" that addresses >> this problem. I imagine llvm should adopt a similar mechanism >> inside cmake. >> >> >> Not sure I follow on the need/use of CC_FOR_TARGET compared to using >> the just-built clang as the CC_FOR_TARGET (which it seems we have &gt...

...rrible problem for Google, but I > do think it is something that should be fixed (I'm working on another > aspect of compiler-rt bringup at the moment, so won't solve this in the > immediate future.) > > > Rightio > > > > gnu systems have a make variable, "CC_FOR_TARGET" that addresses this > problem. I imagine llvm should adopt a similar mechanism inside cmake. > > > Not sure I follow on the need/use of CC_FOR_TARGET compared to using the > just-built clang as the CC_FOR_TARGET (which it seems we have some plumbing > for already - the just-...

I stumbled across what seems to be a bug (to me) in the compiler-rt build: The compiler-rt libraries themselves are built with the host compiler while the tests are built and then linked with the just-built clang. It was my understanding that the goal/intent/need was to have the compiler-rt library build with the just-built clang? Did I misunderstand that?* Sterling: Chandler seemed to think

...rrible problem for Google, but I > do think it is something that should be fixed (I'm working on another > aspect of compiler-rt bringup at the moment, so won't solve this in the > immediate future.) > > > Rightio > > > > gnu systems have a make variable, "CC_FOR_TARGET" that addresses this > problem. I imagine llvm should adopt a similar mechanism inside cmake. > > > Not sure I follow on the need/use of CC_FOR_TARGET compared to using the > just-built clang as the CC_FOR_TARGET (which it seems we have some plumbing > for already - the just-...

...NU_TARGET_ARCH), x86_64) TARGET_CFLAGS=-mno-red-zone +NEWLIB_CFLAGS+=-D_I386MACH_ALLOW_HW_INTERRUPTS endif ifeq ($(GNU_TARGET_ARCH), ia64) TARGET_CFLAGS=-mconstant-gp @@ -97,7 +99,7 @@ $(NEWLIB_STAMPFILE): newlib-cvs $(GCC_STAMPFILE) mkdir -p newlib-build ( cd newlib-build && \ - CC_FOR_TARGET="$(GNU_TARGET_ARCH)-xen-elf-gcc $(TARGET_CFLAGS)" ../newlib-cvs/configure --prefix=$(CROSS_PREFIX) --verbose --target=$(GNU_TARGET_ARCH)-xen-elf --enable-newlib-io-long-long && \ + CC_FOR_TARGET="$(GNU_TARGET_ARCH)-xen-elf-gcc $(TARGET_CFLAGS) $(NEWLIB_CFLAGS)" ../newl...

.../include/public include/xen [ -e include/mini-os ] || ln -sf . include/mini-os [ -e include/x86/mini-os ] || ln -sf . include/x86/mini-os make[2]: Leaving directory `/usr/src/xen-3.3.0/extras/mini-os'' touch mk-headers-x86_32 mkdir -p newlib-x86_32 ( cd newlib-x86_32 && \ CC_FOR_TARGET="gcc -isystem /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/posix -isystem /usr/src/xen-3.3.0/stubdom/../tools/xenstore -isystem /usr/src/xen-3.3.0/stubdom/../extras/mini-os/include/x86 -isystem /u...

...rrible problem for Google, but I > do think it is something that should be fixed (I'm working on another > aspect of compiler-rt bringup at the moment, so won't solve this in the > immediate future.) > > > Rightio > > > > gnu systems have a make variable, "CC_FOR_TARGET" that addresses this > problem. I imagine llvm should adopt a similar mechanism inside cmake. > > > Not sure I follow on the need/use of CC_FOR_TARGET compared to using the > just-built clang as the CC_FOR_TARGET (which it seems we have some plumbing > for already - the just-...

...6,7 @@ NEWLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libc.a .PHONY: cross-newlib cross-newlib: $(NEWLIB_STAMPFILE) -$(NEWLIB_STAMPFILE): newlib-$(NEWLIB_VERSION) +$(NEWLIB_STAMPFILE): mk-headers newlib-$(NEWLIB_VERSION) mkdir -p newlib-build ( cd newlib-build && \ CC_FOR_TARGET="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(NEWLIB_CFLAGS)" AR_FOR_TARGET=$(AR) LD_FOR_TARGET=$(LD) RANLIB_FOR_TARGET=$(RANLIB) ../newlib-$(NEWLIB_VERSION)/configure --prefix=$(CROSS_PREFIX) --verbose --target=$(GNU_TARGET_ARCH)-xen-elf --enable-newlib-io-long-long --disable-multilib &am...

On Dec 16, 2008, at 10:34 AM, Jeffrey Yasskin wrote: > I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also > checked out llvm. Both are synced to r61075. hi Jeffrey, This patch should have fixed the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071210.html Please update and try again, sorry for the breakage! -Chris

...XXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAGE1_CFLAGS=-g" "STAGE1_CHECKING=--enable-checking=yes" "STAGE1_LANGUAGES=c" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/Users/jyasskin/src/llvm-gcc-4.2/clean/obj/./gcc/xgcc -B/Users/jyasskin/src/llvm-gcc-4.2/clean/obj/./gcc/ -B/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/i686-apple-darwin9/bin/ -B/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/i686-apple-darwin9/lib/ -isystem /Users/jyasskin/src/llvm...

I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also checked out llvm. Both are synced to r61075. I'm using Apple's gcc 4.0.1: $ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++