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.