On 10/27/2016 05:00 AM, Rainer Orth wrote:
Hi Jeff,
On 10/19/2016 06:13 AM, Rainer Orth wrote:
Hi Jakub,
2016-10-01 Rainer Orth <r...@cebitec.uni-bielefeld.de>
* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.
This is incomplete. I guess it can be committed as is, but should be
followed by re-addition of:
bfin-*-*)
noconfigdirs="$noconfigdirs target-boehm-gc"
;;
cris-*-* | crisv32-*-*)
case "${target}" in
*-*-linux*)
;;
*) # See PR46792 regarding target-libffi.
noconfigdirs="$noconfigdirs target-boehm-gc";;
esac
;;
mmix-*-*)
noconfigdirs="$noconfigdirs target-boehm-gc"
;;
(perhaps in the same case as target-libffi handling).
sorry I missed this. I can still re-add it if desired, but would rather
keep it in a separate case from the target-libffi handling: in-tree
boehm-gc may be replaced with an external version, while libffi is
likely to stay for libgo.
I think disabling of target-boehm-gc for these targets was because they
didn't support Java for various reasons. However, ISTM that we'd need it
but wouldn't it have been sufficient to just disable libjava in this
case? boehm-gc was only dragged in for libjava (or --enable-objc-gc), IIUC.
It would have been sufficient -- I think it was just overlooked as an
option at the time.
In theory we could build those targets after configuring with
--eanble-objc-gc as a test.
True, but that would need complete cross-development environments for
those targets. I'm certainly not up for that, especially not at this
point.
:-) It was just an observation, certainly not going to require that of
you.
jeff
