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
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
