2012/1/17 Jeremy Bennett <[email protected]>: > On Mon, 2012-01-16 at 21:09 +0100, Olof Kindgren wrote: >> The following change enabled building of the toolchain with the >> bld-all.sh script for me. I couldn't see any side-effects caused by >> bfd_tell, so it seems safe to omit it > > Hi Olof, > > Thanks for this. Some comments below. > >> Index: gnu-src/binutils-2.20.1/bfd/archive64.c >> =================================================================== >> --- gnu-src/binutils-2.20.1/bfd/archive64.c (revision 673) >> +++ gnu-src/binutils-2.20.1/bfd/archive64.c (working copy) >> @@ -43,7 +43,6 @@ >> { >> struct artdata *ardata = bfd_ardata (abfd); >> char nextname[17]; >> - file_ptr arhdrpos; >> bfd_size_type i, parsed_size, nsymz, stringsize, carsym_size, ptrsize; >> struct areltdata *mapdata; >> bfd_byte int_buf[8]; >> @@ -55,7 +54,6 @@ >> ardata->symdefs = NULL; >> >> /* Get the name of the first element. */ >> - arhdrpos = bfd_tell (abfd); >> i = bfd_bread (nextname, 16, abfd); >> if (i == 0) >> return TRUE; > > Is this the upstream patch for this problem? We should use the upstream > patch on the binutils-2.20.1 branch if at all possible (and if not, use > the mainline binutils). That way we avoid issues down the line. > >> To do a test build with gcc 4.6 and make it stop on unused variables, >> I made the following changes to the gnu_make function in the build >> script. That should be all, right? >> >> Index: gnu-src/bld-all.sh >> =================================================================== >> --- gnu-src/bld-all.sh (revision 673) >> +++ gnu-src/bld-all.sh (working copy) >> @@ -627,7 +627,7 @@ >> ${top_srcdir}/configure --target=${target} \ >> --with-pkgversion="${verstr}" --disable-shared \ >> --with-bugurl=http://bugzilla.opencores.org/ \ >> - --with-or1ksim=${or1ksim_dir} --disable-werror \ >> + --with-or1ksim=${or1ksim_dir} \ >> --enable-fast-install=N/A --disable-libssp \ >> --enable-languages=${langs} --prefix=${this_prefix} $* > > Yes - this is a good thing to do. > >> @@ -668,7 +668,7 @@ >> cd $1 >> shift >> >> - make $make_load $* >> + make CC=gcc-4.6 $make_load $* >> >> if [ $? != 0 ] >> then > > This seems a very bad plan. We should not be forcing a particular gcc in > the generic script. Leave this change out. > > You might like to test with GCC 4.6.1 as well (default I think on the > latest Ubuntu). > > If it passes regression as before (I believe there are some failures - > look on the Wiki), then the change is good. > > BTW, the purist approach to portability is to first use your sources to > build a native tool chain, with 3-stage build of the compiler to > validate. Then use that compiler to build the cross-compiler. But I'm > not recommending we do that! > > Best wishes, > > > Jeremy > > -- > Tel: +44 (1590) 610184 > Cell: +44 (7970) 676050 > SkypeID: jeremybennett > Email: [email protected] > Web: www.embecosm.com >
Looking for an upstream patch seems like a good plan. I'll se what I can find Also, the build script changes was just to get feedback on my method, and was not meant to be part of the patch. I need gcc 4.5 for some EDA tool that crashes otherwise, which is why I hard coded 4.6 in the script. -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
