Mike Stump wrote:> On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: >> I've started trying by trying to get sparc-sun-solaris2.10 (niagara) >> working. It appears that neither llvm nor llvm-gcc will build natively >> on the system, so I think that I need to build an llvm-gcc cross >> compiler. > > Get a gcc binary from someplace, use that to then build it, then > install and use that, presto, done, and much easier than anything else.Hmm... I'm not exactly following this. I have gcc installed on all of the systems that I work with.>> The documentation for building gcc (in general) as a cross compiler >> seems to be somewhat dated... > > The scheme has not changed (much) in the past 15 years.Good.>> 4) Build a glibc. > > No, I'd nix this part.OK, I didn't understand the dependency on glibc. I was just following that IBM document.> >> --without-headers > > ? > >> --with-newlib > > ? > > These two are wrong. You don't want to use newlib. You want to use > headers from solaris, as otherwise, you'll get: > >> ../../../../src/llvm-gcc-svn/gcc/tsystem.h:90:19: error: stdio.h: No >> such file or directory > > :-)OK. So I've discovered --with-sysroot which seems to be grabbing and patching the include files correctly. Now it's dieing with ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a function) ./options.h:462: error: bit-field 'padding' width not an integer constant which appears to be llvm-gcc specific because it doesn't happen in vanilla 4.2.4. I'm definitely moving forward though. Thanks for the advice. Luke> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Luke Dalessandro wrote:> OK. So I've discovered --with-sysroot which seems to be grabbing and > patching the include files correctly. Now it's dieing with > > ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a > function) > ./options.h:462: error: bit-field 'padding' width not an integer constant > > which appears to be llvm-gcc specific because it doesn't happen in > vanilla 4.2.4. > > I'm definitely moving forward though. Thanks for the advice.Anton helped me out on irc. For anyone that needs it, the solution was to add #define IN_LIBGCC2 in the beginning of sol2-gmon.c file before its includes. Now I get to an ICE /Users/luked/install/obj/sparc/llvm-gcc/./gcc/xgcc -B/Users/luked/install/obj/sparc/llvm-gcc/./gcc/ -B/Users/luked/opt/sparc/sparc-sun-solaris2.10/bin/ -B/Users/luked/opt/sparc/sparc-sun-solaris2.10/lib/ -isystem /Users/luked/opt/sparc/sparc-sun-solaris2.10/include -isystem /Users/luked/opt/sparc/sparc-sun-solaris2.10/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../../../src/llvm-gcc-svn/gcc -I../../../../src/llvm-gcc-svn/gcc/. -I../../../../src/llvm-gcc-svn/gcc/../include -I../../../../src/llvm-gcc-svn/gcc/../libcpp/include -I/opt/local/include -I/opt/local/include -I../../../../src/llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber -I/Users/luked/install/obj/llvm-svn/include -I/Users/luked/install/src/llvm-svn/include -DL_powitf2 -fvisibility=hidden -DHIDE_EXPORTS -c ../../../../src/llvm-gcc-svn/gcc/libgcc2.c -o libgcc/./_powitf2.o ../../../../src/llvm-gcc-svn/gcc/libgcc2.c: In function '__powitf2': ../../../../src/llvm-gcc-svn/gcc/libgcc2.c:1765: internal compiler error: in HandleArgument, at llvm-abi.h:520 It seems like the sparc-sun-solaris2.10 triple isn't currently supported correctly. I'm considering trying to fix it myself, but my research is in scalable shared memory programming, not the intricacies of gcc and the sparc-solaris ABI. Can anyone give me a feeling on how much time getting llvm-gcc to produce sparc-solaris IR is likely to take someone with 0 familiarity? Or pointers to documentation. Is reading the llvm-gcc source really the best way to learn about it? Thanks, Luke> > Luke > >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I also got this far in compiling llvm-gcc 4.2-2.5 on Solaris 10 on a Niagara 2 machine. Does anyone have a patch/solution for fixing this? LLVM itself compiles just fine. Thanks, Mojtaba On Nov 1 2008, 7:32 am, Luke Dalessandro <lu... at cs.rochester.edu> wrote:> Luke Dalessandro wrote: > > OK. So I've discovered --with-sysroot which seems to be grabbing and > > patching the include files correctly. Now it's dieing with > > > ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a > > function) > > ./options.h:462: error: bit-field 'padding' width not an integer constant > > > which appears to be llvm-gcc specific because it doesn't happen in > > vanilla 4.2.4. > > > I'm definitely moving forward though. Thanks for the advice. > > Anton helped me out on irc. For anyone that needs it, the solution was > to add #define IN_LIBGCC2 in the beginning of sol2-gmon.c file before > its includes. > > Now I get to an ICE > > /Users/luked/install/obj/sparc/llvm-gcc/./gcc/xgcc > -B/Users/luked/install/obj/sparc/llvm-gcc/./gcc/ > -B/Users/luked/opt/sparc/sparc-sun-solaris2.10/bin/ > -B/Users/luked/opt/sparc/sparc-sun-solaris2.10/lib/ -isystem > /Users/luked/opt/sparc/sparc-sun-solaris2.10/include -isystem > /Users/luked/opt/sparc/sparc-sun-solaris2.10/sys-include -O2 -O2 -g > -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 > -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../../../src/llvm-gcc-svn/gcc > -I../../../../src/llvm-gcc-svn/gcc/. > -I../../../../src/llvm-gcc-svn/gcc/../include > -I../../../../src/llvm-gcc-svn/gcc/../libcpp/include > -I/opt/local/include -I/opt/local/include > -I../../../../src/llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber > -I/Users/luked/install/obj/llvm-svn/include > -I/Users/luked/install/src/llvm-svn/include -DL_powitf2 > -fvisibility=hidden -DHIDE_EXPORTS -c > ../../../../src/llvm-gcc-svn/gcc/libgcc2.c -o libgcc/./_powitf2.o > ../../../../src/llvm-gcc-svn/gcc/libgcc2.c: In function '__powitf2': > ../../../../src/llvm-gcc-svn/gcc/libgcc2.c:1765: internal compiler > error: in HandleArgument, at llvm-abi.h:520 > > It seems like thesparc-sun-solaris2.10 triple isn't currently supported > correctly. I'm considering trying to fix it myself, but my research is > in scalable shared memory programming, not the intricacies of gcc and > thesparc-solaris ABI. > > Can anyone give me a feeling on how much time getting llvm-gcc to > producesparc-solaris IR is likely to take someone with 0 familiarity? > Or pointers to documentation. Is reading the llvm-gcc source really the > best way to learn about it? > > Thanks, > Luke > > > > > Luke > > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > > LLVM Developers mailing list > > LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.edu > >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev