[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #11 from Matthias Klose --- > Note libobjc is not used by many folks even > the GNUStep folks don't use it any more ... that's wrong, looking at least at GNUstep base 1.29.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Andrew Pinski --- > Let me look into that for GCC 15. Note libobjc is not used by many folks even > the GNUStep folks don't use it any more ... Thanks. I only include it (and objc-gc) in my builds to maximize coverage on uncommon targets: this tends to find bugs that aren't seen on e.g. Linux.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- Let me look into that for GCC 15. Note libobjc is not used by many folks even the GNUStep folks don't use it any more ...
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Iain Sandoe --- > now that boehm-gc is no longer in tree > > what should we do with this? > > I suppose there could be some more sophisticated top-level configuration > (similar to GMP et. al.) which determines if there's a suitable libgc > available? On the contrary: I think support for --enable-objc-gc at both the toplevel and gcc can just go. * At the toplevel, it's just a preliminary check which I don't think is necessary at all since it's redone in more detail in libobjc. * In gcc, all that --enable-objc-gc does is set OBJC_BOEHM_GC in gcc/Makefile, which isn't ever used.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #7 from Iain Sandoe --- now that boehm-gc is no longer in tree what should we do with this? I suppose there could be some more sophisticated top-level configuration (similar to GMP et. al.) which determines if there's a suitable libgc available?
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > (In reply to Eric Gallager from comment #4) > > (In reply to Eric Gallager from comment #3) > > detecting things > > automatically instead of requiring additional flags; I'm not quite sure how > > to go about making this one automatic now that boehm-gc is no longer > > in-tree, though. detecting automatically (i.e. if the library is in one of the default search paths) != building automatically (e.g. when it was in tree, it would be built if objc was configured). So, in this instance, you could default --enable-objc-gc "on" for darwin, if the configure machinery [for objc-gc] can cope gracefully with the library being present or absent.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #5 from Iain Sandoe --- (In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #3) > > I'll probably keep --enable-objc-gc in my configure flags anyways even if it > > becomes automatic, but becoming automatic could help increase test coverage > > of it. I guess I'll confirm this. > > Note that Iain Sandoe generally prefers configure detecting things > automatically instead of requiring additional flags; I'm not quite sure how > to go about making this one automatic now that boehm-gc is no longer > in-tree, though. this seems to be another set of crossed wires. Darwin only ever used boehm-gc for Java, not for NeXT ObjC the configure option is related to GC for the GNU runtime. In that case, the configuration should work the same as it does for Linux. === The NeXT GC support (if it was implemented, which it isn't) on Darwin uses system-provided libraries (libauto.dylib). Objective-C GC was retired sometime around darwin16, so the motivation is low to put effort into implementing it ahead of more critical missing pieces.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > I'll probably keep --enable-objc-gc in my configure flags anyways even if it > becomes automatic, but becoming automatic could help increase test coverage > of it. I guess I'll confirm this. Note that Iain Sandoe generally prefers configure detecting things automatically instead of requiring additional flags; I'm not quite sure how to go about making this one automatic now that boehm-gc is no longer in-tree, though.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-24 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- I'll probably keep --enable-objc-gc in my configure flags anyways even if it becomes automatic, but becoming automatic could help increase test coverage of it. I guess I'll confirm this.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #2 from Matthias Klose --- this is now documented in install.texi. I have no opinion about the enablement.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 Eric Gallager changed: What|Removed |Added CC||doko at ubuntu dot com, ||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think --enable-objc-gc handling was changed recently; Matthias Klose was the last one to touch it. cc-ing him to see if he thinks we need to leave this open.
