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

Reply via email to