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