Re: [PATCH] Delete GCJ

> On 10 Oct 2016, at 05:03, Matthias Klose <[email protected]> wrote:
>=20
> On 07.10.2016 10:30, Iain Sandoe wrote:
>>=20
>>> On 7 Oct 2016, at 00:58, Matthias Klose <[email protected]> wrote:
>>>=20
>>> On 06.10.2016 20:00, Mike Stump wrote:
>>>> On Oct 6, 2016, at 9:56 AM, Rainer Orth <[email protected]> =
wrote:
>>>>> I wouldn't hard-fail, but completely disable objc-gc with an appropri=
ate
>>>>> warning.  The Objective-C maintainers may have other preferences, tho=
ugh.
>>>=20
>>> I think I can't do that in the top level make file very well (currently=
 I only
>>> have the pkg-config check there for an early failure, but that check do=
esn't
>>> tell me if the library is present for all multilib variants). And I can=
't check
>>> for multilibs because I don't know if the bootstrap compiler is multili=
b aware.
>>=20
>> hrm, so perhaps we need a =E2=80=94with-target-boehm-gc=3D type arrangem=
ent, and it=E2=80=99s the configurer=E2=80=99s responsibility to provide a =
path with appropriate headers/libs for the multi-lib configuration being at=
tempted.
>=20
> I don't understand what you are proposing here.

given that:
 auto-detection of the capabilities could be quite difficult (or, in the ge=
neral case, unachievable) for the reasons you gave.
 the chosen target libraries might be in a non-standard place.

making it an explicit requirement to point to them, and to ensure that the =
versions/multi-libs provided are suitable, (by putting =E2=80=94with-target=
-boehm-gc=3D/path/to/suitable/) would mean that the dependent configury (fo=
r objc-gc) could be just conditional upon the  presence of the "with-target=
-boehm-gc=E2=80=9D.

I suppose that one could make "=E2=80=94with-target-boehm-gc=E2=80=9D (no a=
ttached path) declare that the library (and requisite mult-lib versions) wi=
ll be found in the sysroot without any additional work.

The point here was to simplify the dependent configury so that it only need=
s to test something that the configuring user specifies (i.e. if they speci=
fy objc-gc, then they need also to specify the place that the gc lib can be=
 found).

>>>> gcc historically is fairly weak at complex configurations.  I need the=
 32 bit libraries to support -m32, but, those libraries might not be presen=
t, but do I build all the rest of my libraries, and if i do, do I test them=
 once build, but what is other dependent external libraries are missing.  D=
o I turn off the multilib, or do I not?
>>>>=20
>>>> I used to manage some of this by passing in configure flags to control=
 multilibbing based upon what libraries were install and then run testing b=
ased upon that.  Of course, that's all external to gcc proper. Doesn't real=
ly make gcc any easier to configure and build or advance gcc.
>>>>=20
>>>> We could smell the system at configure time, and turn on and off multi=
lib variants and things like objc gc. Target specific, but I think it helps=
 to ponder this in a target independent way.  This can then turn on and off=
 objc gc support directly.  To get it on, one would need to install the nee=
ded libraries, and reconfigure and rebuild gcc.  I think I might like that =
the best.  Has a nice easy of use about it, and then everything gcc does is=
 rather sane (no funny build errors when a needed library isn't present).
>>>>=20
>>>>=20
>>>> So, I think, if I understand what you propose, I'm fine with that.
>>>=20
>>> So your proposal is to replace the ": dnl ..." line in libobjc/configur=
e.ac with
>>> a hard error message and leave it to the user to correctly configure GC=
C?  That
>>> would rely on the compiler to find the library in a system wide multili=
b aware
>>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the c=
ase for
>>> Solaris and Darwin?
>>=20
>> for Darwin, it=E2=80=99s not a default install (but then neither are the=
 host deps such as gmp & friends) - so the toolchain builder on Darwin alre=
ady needs to make some provisions outside the system.  It=E2=80=99s just th=
at the only target provisions to date have been the sysroot (we haven=E2=80=
=99t yet made use of add-on target libs).
>>=20
>>> I'm fine with that, it wouldn't affect configurations like x86_64-linux=
-gnu
>>> where multilib is the default (but objc-gc is not).
>>>=20
>>> Looking back at libjava, I think everybody disabled multilibs for libja=
va,
>>> because nobody had a complete gtk2 stack for multilibs, however that wa=
s a
>>> complete subdir, not just a certain configuration in that subdir. Looki=
ng back
>>> at libffi and separate released libffi's I first built multilib'ed libf=
fi
>>> libraries from the libffi source for Debian/Ubuntu, then dropped these =
because
>>> they were not used, and until today GCC internal and external libffi are
>>> hopelessly out of sync, so you couldn't use an external libffi to build=
 libjava.
>>=20
>> Becase Darwin=E2=80=99s libjava does not depend on the gtk2 stack, actua=
lly normally libjava (and libffi, gc) were generally built and tested (by t=
hose who cared to do it) as multilibs [the default].
>>>=20
>>> In the past I looked at updating boehm-gc to recent sources but never f=
inished
>>> because libjava relied on internals.  Afaics this is not the case for o=
bjc-gc,
>>> so maybe you could update boehm-gc. But I don't want to go this road my=
self =E2=80=A6
>>=20
>> .. and I don=E2=80=99t have cycles to volunteer to try this at present e=
ither.
>> Iain
>>=20
>>=20
>>>=20
>>> Matthias
>>=20
>=20