similar to: [LLVMdev] strange visibility error when compiling llvm-gcc-4.2

Hi, > if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/svn.gcc42/libgomp/config/linux/x86

On Feb 6, 2008, at 5:18 AM, Duncan Sands wrote: > Hi, > >> if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/ >> s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/ >> local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/ >> include -isystem /usr/local/i686-pc-linux-gnu/sys-include - >> DHAVE_CONFIG_H -I.

On 2/6/08, Chris Lattner <sabre at nondot.org> wrote: > > On Feb 6, 2008, at 5:18 AM, Duncan Sands wrote: > > > Hi, > > > >> if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/ > >> s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/ > >> local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/ >

Hi, I see this when building llvm-gcc on x86-32 linux: xgcc -Bgcc/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/bin/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/i686-pc-linux-gnu/include -isystem /usr/local/gnat-llvm/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.llvm/libgomp -I. -I../../../gcc-4.2.llvm/libgomp/config/linux/x86

Hi, Sorry for breakage, I'll look into this right now. I guess llvm-gcc doesn't use llvm tablegen results to help create intrinsic names. -- Mon Ping On Jul 30, 2008, at 1:51 PM, Duncan Sands wrote: > Hi, I see this when building llvm-gcc on x86-32 linux: > > xgcc -Bgcc/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/bin/ -B/usr/ > local/gnat-llvm/i686-pc-linux-gnu/lib/

On Jul 30, 2008, at 2:03 PMPDT, Mon P Wang wrote: > Hi, > > Sorry for breakage, I'll look into this right now. I guess llvm-gcc > doesn't use llvm tablegen results to help create intrinsic names. > > -- Mon Ping It calls Intrinsic::getDeclaration. > On Jul 30, 2008, at 1:51 PM, Duncan Sands wrote: > >> Hi, I see this when building llvm-gcc on x86-32

x86-64 linux, during stage3: xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/include -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.llvm/libgomp -I.

Hi Bill, This is probably due to the llvm-gcc merge. Please take a look. Thanks, Evan On Jul 30, 2008, at 10:04 AM, Duncan Sands wrote: > x86-64 linux, during stage3: > > xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/ > gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/ > x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

The curent llvm svn (r54623) is unable to link the gfortran compiler in llvm-gcc-4.2 svn. I am getting the error... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

Duncan, Actually, shouldn't this be just an error in the Makefile.in or Makefile.am? Why should a link line like... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > Not sure if that's related, but we had two failures last night as > well: > > MacOS/Universal build failed on rev 54197, when building the x86->ppc > cross: > > cc1: warnings being treated as errors > /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: > no > previous prototype for

I'm getting following errors while cross compiling llvm for ARM. Please help since it is urgent and critical My gcc version is 4.2.0, 32bit Linux and target is ARM Configure options are: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home//arm_v7_vfp_le/target/

On 2010-06-04 13:41, Sanjeev C wrote: > I get following errors: > > /home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/xgcc > -B/home/llvm-gcc-4.2-2.7.source/host-i686-pc-linux-gnu/gcc/ > -B/usr/local/armv7fl-montavista-linux-gnueabi/bin/ > -B/usr/local/armv7fl-montavista-linux-gnueabi/lib/ -isystem > /usr/local/armv7fl-montavista-linux-gnueabi/include -isystem >

Hi Jack, > The curent llvm svn (r54623) is unable to link the gfortran > compiler in llvm-gcc-4.2 svn. I am getting the error... ... > Undefined symbols: > "_create_init_utf16_var", referenced from: > _darwin_build_constant_cfstring in libbackend.a(darwin.o) this is probably due to recent Apple changes. Fortran builds on linux. > Why is c++ being used

I've created fink packaging for a building the llvm and llvm-gcc-4.2 svn pulls under fink on Mac OS X. Hopefully the fink info script and patch should be clear enough for some comments on my build approach. The llvm-gcc and llvm-g++ compilers seem okay so far. The llvm-gfortran compiler seems to always spew a warning.. WARNING: 128-bit integers not supported! ...even when just compiling a

Hi, > I am confused. Shouldn't the gcc 4.2 front-end build behave > just like the FSF gcc build. The first stage builds the compilers > and the second stage rebuilds them using those from the first > stage? the FSF gcc requires you to build the C compiler (I think - will check). Thus a newly built C compiler is always available to build later stages. We can't reasonably

On Jun 11, 2009, at 7:18 PM, Misha Brukman wrote: > I've committed my scripts that simplify building Linux/x86 -> Linux/ > ARM crosstool. There are 2 parts to using this: > > * llvm/utils/crosstool/create-snapshots.sh > creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific > revision of your choice > * llvm/utils/crosstool/ARM/build-install-linux.sh

Duncan, I am confused. Shouldn't the gcc 4.2 front-end build behave just like the FSF gcc build. The first stage builds the compilers and the second stage rebuilds them using those from the first stage? Jack On Mon, Aug 11, 2008 at 03:56:23PM +0200, Duncan Sands wrote: > > I don't be that can be the cause because I have... > > > >

Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is failing here with... /sw/src/fink.build/llvm-gcc42-2.9-0/llvm_gcc42_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/llvm-gcc42-2.9-0/llvm_gcc42_objdir/./prev-gcc/ -B/sw/lib/llvm-gcc-4.2/x86_64-apple-darwin10/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes