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.
> for objc-gc. So I think we shouldn't be adding these hunks at this point.
Fine with me ;-)
> 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.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
