sh-elf build failure on mainline]

David Ayers d.ayers@inode.at
Thu Jun 15 13:16:00 GMT 2006


Andrew Haley schrieb:
> David Ayers writes:
> 
>  > 
>  > Is this a useful configuration?  i.e. should try to:
>  > a) disable the 'java' front-end for sh-elf
>  > b) change the logic of my case statement to evaluate libgcj instead of
>  > enabled_languages
> 
> I don't believe that anyone has ever managed to use the gcj front-end
> without libgcj.  However, it is in theory possible to build them
> separately, so I'm reluctant to disallow building the compiler on its
> own.
> 
> libffi and target-boehm-gc are required by the libgcj runtime, not by
> the gcj front-end.

OK, I'm running this through a native bootstrap on i686-pc-linux-gnu and
a cross build on sh-elf (sh-unknown-elf) simulator.

Here is the plain code for better readability:

# Make sure we only build Boehm's garbage collector if required.
case ,${enable_language},:${enable_objc_gc} in
  *,objc,*:yes)
    # Keep target-boehm-gc if requested for Objective-C.
    ;;
  *)
    # Otherwise remove target-boehm-gc depending on target-libjava.
    if echo " ${noconfigdirs} " | grep "target-libjava" >/dev/null 2>&1;
then
      noconfigdirs="$noconfigdirs target-boehm-gc"
    fi
    ;;
esac


OK for mainline (once the builds and complete)?

Cheers,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc.patch
Type: text/x-patch
Size: 1247 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20060615/8342467b/attachment.bin>


More information about the Gcc-patches mailing list