Re: [PATCH] Delete GCJ

Mike Stump <[email protected]> Thu, 6 Oct 2016 11:00:54 -0700
Newsgroups gmane.comp.gcc.patches,gmane.comp.gcc.java.patches
Message-ID <[email protected]>
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 appropriate
> warning.  The Objective-C maintainers may have other preferences, though.

gcc historically is fairly weak at complex configurations.  I need the 32 b=
it libraries to support -m32, but, those libraries might not be present, bu=
t 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 t=
urn off the multilib, or do I not?

I used to manage some of this by passing in configure flags to control mult=
ilibbing 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 m=
ake gcc any easier to configure and build or advance gcc.

We could smell the system at configure time, and turn on and off multilib v=
ariants 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 obj=
c 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 rat=
her 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.