[PATCH] Delete GCJ

Matthias Klose doko@ubuntu.com
Thu Oct 6 23:59:00 GMT 2016

On 06.10.2016 20:00, Mike Stump wrote:
> On Oct 6, 2016, at 9:56 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate
>> warning.  The Objective-C maintainers may have other preferences, though.

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 doesn'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.

> gcc historically is fairly weak at complex configurations.  I need the 32 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 once build, but what is other dependent external libraries are missing.  Do I turn off the multilib, or do I not?
> 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 based 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.
> We could smell the system at configure time, and turn on and off multilib 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 needed 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).
> So, I think, if I understand what you propose, I'm fine with that.

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 case for
Solaris and Darwin?

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).

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 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.

In the past I looked at updating boehm-gc to recent sources but never finished
because libjava relied on internals.  Afaics this is not the case for objc-gc,
so maybe you could update boehm-gc. But I don't want to go this road myself ...


More information about the Java-patches mailing list