Re: [PATCH] Delete GCJ

Iain Sandoe <[email protected]> Fri, 7 Oct 2016 09:30:54 +0100
Newsgroups gmane.comp.gcc.java.patches,gmane.comp.gcc.patches
Message-ID <[email protected]>
> 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]> wr=
ote:
>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>>> warning.  The Objective-C maintainers may have other preferences, thoug=
h.
>=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 does=
n'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 multilib =
aware.

hrm, so perhaps we need a =E2=80=94with-target-boehm-gc=3D type arrangement=
, and it=E2=80=99s the configurer=E2=80=99s responsibility to provide a pat=
h with appropriate headers/libs for the multi-lib configuration being attem=
pted.
>=20
>> gcc historically is fairly weak at complex configurations.  I need the 3=
2 bit libraries to support -m32, but, those libraries might not be present,=
 but do I build all the rest of my libraries, and if i do, do I test them o=
nce build, but what is other dependent external libraries are missing.  Do =
I turn off the multilib, or do I not?
>>=20
>> I used to manage some of this by passing in configure flags to control m=
ultilibbing based upon what libraries were install and then run testing bas=
ed upon that.  Of course, that's all external to gcc proper. Doesn't really=
 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 multili=
b variants and things like objc gc. Target specific, but I think it helps t=
o ponder this in a target independent way.  This can then turn on and off o=
bjc gc support directly.  To get it on, one would need to install the neede=
d libraries, and reconfigure and rebuild gcc.  I think I might like that th=
e best.  Has a nice easy of use about it, and then everything gcc does is r=
ather 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/configure.=
ac with
> a hard error message and leave it to the user to correctly configure GCC?=
  That
> would rely on the compiler to find the library in a system wide multilib =
aware
> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32).  Is this the cas=
e for
> Solaris and Darwin?

for Darwin, it=E2=80=99s not a default install (but then neither are the ho=
st deps such as gmp & friends) - so the toolchain builder on Darwin already=
 needs to make some provisions outside the system.  It=E2=80=99s just that =
the only target provisions to date have been the sysroot (we haven=E2=80=99=
t yet made use of add-on target libs).

> I'm fine with that, it wouldn't affect configurations like x86_64-linux-g=
nu
> where multilib is the default (but objc-gc is not).
>=20
> Looking back at libjava, I think everybody disabled multilibs for libjava,
> because nobody had a complete gtk2 stack for multilibs, however that was a
> complete subdir, not just a certain configuration in that subdir. Looking=
 back
> at libffi and separate released libffi's I first built multilib'ed libffi
> libraries from the libffi source for Debian/Ubuntu, then dropped these be=
cause
> 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 l=
ibjava.

Becase Darwin=E2=80=99s libjava does not depend on the gtk2 stack, actually=
 normally libjava (and libffi, gc) were generally built and tested (by thos=
e who cared to do it) as multilibs [the default].
>=20
> In the past I looked at updating boehm-gc to recent sources but never fin=
ished
> because libjava relied on internals.  Afaics this is not the case for obj=
c-gc,
> so maybe you could update boehm-gc. But I don't want to go this road myse=
lf =E2=80=A6

.. and I don=E2=80=99t have cycles to volunteer to try this at present eith=
er.
Iain


>=20
> Matthias