We have a fairly complete coverage of packages for R 4.0.0, but one exception is GTK+ (and thus RGtk2 and its dependencies). It seems that GTK+ has been abandoned several years ago, the documented macOS build doesn't work and there are no released binaries. To make things worse, Gnome has been switching from autoconf to custom build systems that are also broken (quite amazing - the build fails with an error in the build system's headers including Python headers...), so the path of building our own release from scratch is also not realistic anymore (we used to build GTK+ for X11 when it was still possible). Hence this is a call to the R community to see if anyone actually cares. And if so, if there is any known source or path to macOS binaries (script to build it is fine, too). Unlike regular rules, we would allow dynamic linking as we have granted that exception to GTK+ before, but it has to be compatible with the native system. As a last resort, we could also re-use out GTK+ 2.24.17 binaries from Snow Leopard, but those are considerably old, so I'd prefer not to do that. Comments are welcome. Thanks, Simon
GTK+ support (or rather lack thereof)
6 messages · Kevin Ushey, Michael Lawrence, Tom Elliott +2 more
For what it's worth, Homebrew and macports both have scripts for installing GTK+ from sources, so presumedly those could be cribbed into a standalone shell script for a build if desired: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gtk+.rb https://github.com/macports/macports-ports/blob/master/gnome/gtk2/Portfile Would that be worth exploring? I'd be willing to try and put something together if so. Also -- is the intention to stick with the latest patch release of the GTK+ 2.x series, or try to upgrade to GTK+ 3.x? (I suspect that GTK+-using packages would likely need to adapt to changes in GTK+ 3.x) Kevin On Thu, Apr 2, 2020 at 6:03 PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
We have a fairly complete coverage of packages for R 4.0.0, but one exception is GTK+ (and thus RGtk2 and its dependencies). It seems that GTK+ has been abandoned several years ago, the documented macOS build doesn't work and there are no released binaries. To make things worse, Gnome has been switching from autoconf to custom build systems that are also broken (quite amazing - the build fails with an error in the build system's headers including Python headers...), so the path of building our own release from scratch is also not realistic anymore (we used to build GTK+ for X11 when it was still possible). Hence this is a call to the R community to see if anyone actually cares. And if so, if there is any known source or path to macOS binaries (script to build it is fine, too). Unlike regular rules, we would allow dynamic linking as we have granted that exception to GTK+ before, but it has to be compatible with the native system. As a last resort, we could also re-use out GTK+ 2.24.17 binaries from Snow Leopard, but those are considerably old, so I'd prefer not to do that. Comments are welcome. Thanks, Simon
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
If we have working 2.24.17 binaries, let's just use them. GTK+ was already super mature by that point; it's unlikely that many improvements/fixes were made. I'll start looking into RGtk3. Actually, I started that like 8 years ago. Michael
On Fri, Apr 3, 2020 at 9:43 AM Kevin Ushey <kevinushey at gmail.com> wrote:
For what it's worth, Homebrew and macports both have scripts for installing GTK+ from sources, so presumedly those could be cribbed into a standalone shell script for a build if desired: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gtk+.rb https://github.com/macports/macports-ports/blob/master/gnome/gtk2/Portfile Would that be worth exploring? I'd be willing to try and put something together if so. Also -- is the intention to stick with the latest patch release of the GTK+ 2.x series, or try to upgrade to GTK+ 3.x? (I suspect that GTK+-using packages would likely need to adapt to changes in GTK+ 3.x) Kevin On Thu, Apr 2, 2020 at 6:03 PM Simon Urbanek <simon.urbanek at r-project.org> wrote:
We have a fairly complete coverage of packages for R 4.0.0, but one
exception is GTK+ (and thus RGtk2 and its dependencies). It seems that GTK+ has been abandoned several years ago, the documented macOS build doesn't work and there are no released binaries. To make things worse, Gnome has been switching from autoconf to custom build systems that are also broken (quite amazing - the build fails with an error in the build system's headers including Python headers...), so the path of building our own release from scratch is also not realistic anymore (we used to build GTK+ for X11 when it was still possible).
Hence this is a call to the R community to see if anyone actually cares.
And if so, if there is any known source or path to macOS binaries (script to build it is fine, too). Unlike regular rules, we would allow dynamic linking as we have granted that exception to GTK+ before, but it has to be compatible with the native system. As a last resort, we could also re-use out GTK+ 2.24.17 binaries from Snow Leopard, but those are considerably old, so I'd prefer not to do that. Comments are welcome.
Thanks, Simon
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Michael Lawrence Senior Scientist, Bioinformatics and Computational Biology Genentech, A Member of the Roche Group Office +1 (650) 225-7760 michafla at gene.com Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube [[alternative HTML version deleted]]
Simon,
Hence this is a call to the R community to see if anyone actually cares.
I (and Chris Wild and quite a few of our mac users) care and would greatly appreciate working GTK+ CRAN packages! I don't have any knowledge re source etc, but just to remind you that the current RGtk2 package on CRAN for 3.3 doesn't work (or at least wasn't when I last tried): library(RGtk2) gtkHScaleNewWithRange(0, 5, 1) # segfault Cheers, - Tom
On 04/04/2020 05:15, Tom Elliott wrote:
Simon,
Hence this is a call to the R community to see if anyone actually cares.
I (and Chris Wild and quite a few of our mac users) care and would greatly appreciate working GTK+ CRAN packages! I don't have any knowledge re source etc, but just to remind you that the current RGtk2 package on CRAN for 3.3 doesn't work (or at least wasn't when I last tried): library(RGtk2) gtkHScaleNewWithRange(0, 5, 1) # segfault
Did you really mean '3.3'? If so, R versions that old are long unsupported. FWIW, your example worked for me with 4.0.0 alpha and RGtk2 built from source against Simon's (old) build of GTK+ 2.24.17. Have you tried that? RGtk2 and some of the packages using it pass their checks but some (e.g. gWidgets2RGtk2 and a few of those using it including MixSIAR, Ricetl, fit4NM, plfMA) segfault. And this has been the case for several years.
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford
Thanks for the confirmation, Brian. I wasn't aware that Gtk+2 was abandoned for so long - then our 2.24.17 binaries are in fact quite reasonable and I'll go with that. Thanks, Simon
On 4/04/2020, at 9:11 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: On 04/04/2020 05:15, Tom Elliott wrote:
Simon,
Hence this is a call to the R community to see if anyone actually cares.
I (and Chris Wild and quite a few of our mac users) care and would greatly appreciate working GTK+ CRAN packages! I don't have any knowledge re source etc, but just to remind you that the current RGtk2 package on CRAN for 3.3 doesn't work (or at least wasn't when I last tried): library(RGtk2) gtkHScaleNewWithRange(0, 5, 1) # segfault
Did you really mean '3.3'? If so, R versions that old are long unsupported. FWIW, your example worked for me with 4.0.0 alpha and RGtk2 built from source against Simon's (old) build of GTK+ 2.24.17. Have you tried that? RGtk2 and some of the packages using it pass their checks but some (e.g. gWidgets2RGtk2 and a few of those using it including MixSIAR, Ricetl, fit4NM, plfMA) segfault. And this has been the case for several years. -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac