[R-SIG-Mac] Mac OS X tcltk/X11 issues

Simon Urbanek simon.urbanek at r-project.org
Fri Jul 18 16:26:31 CEST 2014 

On Jul 18, 2014, at 5:17 AM, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote:

> On Thu, Jul 17, 2014 at 2:05 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> On Jul 15, 2014, at 3:01 PM, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote:
> 
> > Prof Ripley and other people involved with tcltk,
> >
> > You could have the tcltk building routine leave some evidence behind re.
> > how it was build.
> >
> > For example, in Rgraphviz we used to grapple with something similar at the
> > abstract level - was the Graphviz version used to build a binary
> > distributed version of Rgraphviz, the same as the Graphviz installed by the
> > user (if there was a version mismatch on Windows, there was a high chance
> > of an arcane error time).  As part of running configure, we save the
> > Graphviz version at build time into a variable kept in a file in /R.
> > Specifically we have a file
> > R/graphviz_build_version.R.in
> > which contains something like
> >  graphviz_build_version=@GRAPHVIZ_BUILD@
> > configure does the usual transformation (code here is from memory).
> >
> > This was then checked in .onLoad before the Rgraphviz dynamic library was
> > loaded.  Now the code is different, because we bundle Graphviz with
> > Rgraphviz.
> >
> > Something similar should not be too hard to introduce for tcltk to keep a
> > record of how it was build.
> >
> > We see a lot of noise about this issue, so it may be worthwhile to solve
> > robustly.
> >
> 
> Well, but the above is entirely irrelevant to the discussion at hand (AFAICT). The problem here is that we are talking about *binary* distribution - so the build process was indeed created in a fully working environment, but the user failed to re-create the environment and thus the assumptions at build time are broken. The assumptions are directly at the linking level, and the dependency that fails is not even under our control - X11 installation - so it's not something we can modify
> 
> It seems that Prof. Ripley has fixed this, but I still want to reply to this.
> 
> As I can tell, this is exactly the same as with tcltk: The binary version of Rgaphviz build on the Bioconductor Windows machines used a specific version of Graphviz, which (it used to be) was the user's responsibility to create.  If the user failed to do so, the package would throw an error when loaded.   
> 

Yes, but in our case it's *not* the direct dependency - i.e. we do control Tcl/Tk which we build and we could check that it's missing, but the thread here is about X11 missing which is not a direct dependency and thus not something we have control over. Also this is not about versions - it's about availability. Moreover, the actual X11 binary can be very different - it can be anything from Apple's X11 to Xquartz or even a custom build (however unlikely).

Cheers,
Simon


> Best,
> Kasper
> 
> 
>  
> Brian did indeed describe quite precisely the various issues involved here.
> 
> IMHO the other contributions are a bit off track - I would argue that this is only about CRAN binary so adding a very specific extra check in R along the lines of what Brian proposed is the most robust and relevant way forward (note that the check may be identical for the X11 device). We're certainly not talking about a cross-platform solution but rather a very specific solution for the CRAN binary.
> 
> Cheers,
> Simon
> 
> 
> 
> > Best,
> > Kasper
> >
> >
> > On Tue, Jul 15, 2014 at 4:16 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk>
> > wrote:
> >
> >> John talked to me about this a month ago and after some sick
> >> leave/vacation I had just got around to thinking into it.
> >>
> >> Minor points:
> >>
> >> 1) The usual way to check for OS X in the R sources is
> >> grepl("darwin", R.version$os)
> >>
> >> 2) It is perfectly possible to build R on Linuxen without X11
> >> headers/libraries.
> >>
> >> 3) There are three branches to the Tk code, X11, Aqua and Windows.  So
> >> apart from on Windows and OS X you either use X11 or do not have Tk.
> >>
> >> 4) It is possible to build R without Tcl/Tk, in which case you get a stub
> >> tcltk package.  Then capabilities('tcltk') tells you that you have the stub.
> >>
> >> 5) Just so we are all understand, it is possible (and documented in the
> >> manuals) for tcltk to be built using the Aqua Tk branch, and then Rcmdr
> >> works well (in my opinion much better) without X11 present.  So we do not
> >> want Rcmdr checking unconditionally for X11 being present.
> >>
> >>
> >> My understanding is that the main problem is that if someone installs one
> >> of the CRAN binary packages for OS X and does not have X11 installed then
> >> library(tcltk) will fail with a message that they do not understand, e.g.
> >> https://stat.ethz.ch/pipermail/r-sig-mac/2014-July/010954.html .
> >>
> >> For the future, probably the best thing to do is for the tcltk startup
> >> code to try to trap that case and suggest that X11/XQuartz needs to be
> >> installed.  The problem is accurately identifying 'that case'.
> >>
> >> If a package has tcltk in the imports of its NAMESPACE, there is nothing
> >> it can do about a broken tcltk as the namespaces it imports will be
> >> processed before any of the code in the package.  So the other possibility
> >> is to not have tcltk in the imports but to load its namespace via
> >> Rcmd::.onLoad.  I figured out how to to do that but it would be rather
> >> fragile.
> >>
> >>
> >> There is another possible problem which is that X11 is installed but a X
> >> server is not running.  That's what capabilities('X11') checks, and on
> >> modern OS X it ought to launch the X server as required.  However, I do not
> >> think we have a way to telling which Tk branch package tcltk was built
> >> against.  Since that is only an issue on OS X (no other OS can use more
> >> than one branch) you could use something like
> >>
> >> Tk_is_X11 <- function()
> >> {
> >>    DLL <- system.file("libs", "tcltk.so", package = "tcltk")
> >>    out <- system2("otool", c("-L", shQuote(DLL)), stdout = TRUE)
> >>    length(grep("libX11[.][0-9]+[.]dylib", out)) > 0L
> >> }
> >>
> >> and then
> >>
> >> if (.Platform$OS.type == "unix") {
> >>   if (!grepl("darwin", R.version$os) || Tk_is_X11())
> >>       if(!capabilities("X11"))
> >>            stop("Rcmdr requires a running X server")
> >>
> >> }
> >>
> >>
> >> On 15/07/2014 13:05, Marc Schwartz wrote:
> >>
> >>> John,
> >>>
> >>> First, apologies for my narrow focus on the solutions that I proposed
> >>> yesterday. I suffered from tunnel vision on the OS X issue and as Gabor has
> >>> noted, it would not be sufficiently portable. There can be potential
> >>> variations on where X11 is installed on OS X, depending upon the use of
> >>> Xquartz, the original Apple distribution of X11 and presumably could
> >>> further vary if one installs from source, is using Homebrew, Macports or
> >>> similar, which are package management systems for OS X. Thus, as Gabor
> >>> pointed out, capabilities("X11") is the most portable approach.
> >>>
> >>> With respect to Linux, to the best of my knowledge, X11 (for some time
> >>> X.org) is still a requirement for tk (but not tcl). In checking at least
> >>> the current Fedora repos, X11 is still listed as a dependency for tk. So if
> >>> one is using the common package management systems, X11 will be installed
> >>> if not already, when installing tk, unless one overrides the defaults.
> >>>
> >>> Also, at least for Fedora and perhaps other Linuxen, X11 is listed as a
> >>> dependency for R itself, so if one is installing R on Fedora, X11 will be
> >>> installed as well, if not present.
> >>>
> >>> Thus, between the common Linux package management systems and that Linux
> >>> users tend to be more technically saavy, you do not see many reports.
> >>>
> >>> You likely already know this, but you could utilize a more generic
> >>> approach to testing the platform by using:
> >>>
> >>>   if (.Platform$OS.type == "unix")
> >>>     ...
> >>>
> >>> which would cover Linuxen, Unixen and OS X and then run your X11 checks,
> >>> secondarily perhaps testing for OS X, if you wish to give a more specific
> >>> error message for OS X users and point them to XQuartz.
> >>>
> >>> Regards,
> >>>
> >>> Marc
> >>>
> >>>
> >>>
> >>> On Jul 14, 2014, at 11:37 PM, John Fox <jfox at mcmaster.ca> wrote:
> >>>
> >>> Hi Gabor,
> >>>>
> >>>> Thanks for the clarification.
> >>>>
> >>>> I agree that it would be best to intercept the problem on Linux/Unix as
> >>>> well as on Mac OS X. Do you know that X11 is necessary for the tcltk
> >>>> package to work on Linux/Unix systems (or is there possibly a non-X11
> >>>> Tcl/Tk there that's compatible with the tcltk package)?
> >>>>
> >>>> As a practical matter, the problem occurs with some regularity on Mac OS
> >>>> X (I'm aware that the availability and default installation of X11 varies
> >>>> by version of the OS), but I've not seen a report of it on Linux, so my
> >>>> immediate concern was to solve the problem on Mac OS X.
> >>>>
> >>>> Best,
> >>>> John
> >>>>
> >>>> On Mon, 14 Jul 2014 21:37:54 -0400
> >>>> Gábor Csárdi <csardi.gabor at gmail.com> wrote:
> >>>>
> >>>>> Hi John,
> >>>>>
> >>>>> On Mon, Jul 14, 2014 at 8:12 PM, John Fox <jfox at mcmaster.ca> wrote:
> >>>>>
> >>>>>> Dear Gabor,
> >>>>>>
> >>>>>> As I just explained, the problem isn't testing for X11, which I know
> >>>>>> how to do -- though capabilities("X11") is a bit better than what I
> >>>>>> suggested. The issue is specific to Mac OS X because the Windows
> >>>>>> implementation of R includes a Tcl/Tk that doesn't use X11, and I've never
> >>>>>> seen the problem on Linux.
> >>>>>>
> >>>>>
> >>>>> actually, what I am saying is, that it is not specific to OSX. Some
> >>>>> (older, before 2012) OSX versions do include an X11 server, and some
> >>>>> Linux or other Unix installations do not.
> >>>>>
> >>>>> I am not saying tcltk should not test for an X11 server, all I am
> >>>>> saying is that the test suggested below (based on the os and the
> >>>>> existence of a certain file) is not the best one.
> >>>>>
> >>>>> If it turns out that there is no X11 server, and the os is OSX, then
> >>>>> indeed a dialog box could be displayed, see e.g. the one at
> >>>>> http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-
> >>>>> x-mountain-lion-shifts-support-to-open-source-xquartz/
> >>>>>
> >>>>> Best,
> >>>>> Gabor
> >>>>>
> >>>>> Best,
> >>>>>> John
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>>> From: Gábor Csárdi [mailto:csardi.gabor at gmail.com]
> >>>>>>> Sent: Monday, July 14, 2014 6:37 PM
> >>>>>>> To: Marc Schwartz
> >>>>>>> Cc: John Fox; urbanek at research.att.com; R-SIG-Mac
> >>>>>>> Subject: Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
> >>>>>>>
> >>>>>>> What's wrong with capabilities("X11")?
> >>>>>>>
> >>>>>>> I am not sure if teting for the OS, and especially for a particular X
> >>>>>>> server, installed in a particular directory, is a good idea, even if
> >>>>>>> it covers most of the _current_ installations.
> >>>>>>>
> >>>>>>> Gabor
> >>>>>>>
> >>>>>>> On Mon, Jul 14, 2014 at 6:13 PM, Marc Schwartz <marc_schwartz at me.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 14, 2014, at 4:53 PM, Marc Schwartz <marc_schwartz at me.com>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 14, 2014, at 4:13 PM, John Fox <jfox at mcmaster.ca> wrote:
> >>>>>>>>>
> >>>>>>>>> Dear Simon and list members,
> >>>>>>>>>>
> >>>>>>>>>> As many of you are aware, when X11 isn't installed on Mac OS X,
> >>>>>>>>>>
> >>>>>>>>> loading the
> >>>>>>>
> >>>>>>>> tcltk package produces an error, with a message that many users
> >>>>>>>>>>
> >>>>>>>>> find
> >>>>>>>
> >>>>>>>> cryptic. There was yet another instance of this problem reported to
> >>>>>>>>>>
> >>>>>>>>> the list
> >>>>>>>
> >>>>>>>> today.
> >>>>>>>>>>
> >>>>>>>>>> I'm interested in the issue because the Rcmdr package uses tcltk
> >>>>>>>>>>
> >>>>>>>>> and thus
> >>>>>>>
> >>>>>>>> fails to load when X11 is absent. Rcmdr users tend to be
> >>>>>>>>>>
> >>>>>>>>> inexperienced and
> >>>>>>>
> >>>>>>>> so, unless they find their way to the Rcmdr installation webpage,
> >>>>>>>>>>
> >>>>>>>>> where
> >>>>>>>
> >>>>>>>> detailed installation instructions are provided, they tend to be
> >>>>>>>>>>
> >>>>>>>>> stymied by
> >>>>>>>
> >>>>>>>> the problem.
> >>>>>>>>>>
> >>>>>>>>>> If I could, I'd intercept the problem by checking
> >>>>>>>>>>
> >>>>>>>>> capabilities()["X11"] in
> >>>>>>>
> >>>>>>>> the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr
> >>>>>>>>>>
> >>>>>>>>> package
> >>>>>>>
> >>>>>>>> imports the tcltk namespace, the error occurs before these startup
> >>>>>>>>>>
> >>>>>>>>> functions
> >>>>>>>
> >>>>>>>> are executed -- a chicken-and-egg problem.
> >>>>>>>>>>
> >>>>>>>>>> It occurs to me that tcltk could fail more gracefully on Mac OS X
> >>>>>>>>>>
> >>>>>>>>> when X11
> >>>>>>>
> >>>>>>>> is absent, perhaps popping up a webpage in a browser with
> >>>>>>>>>>
> >>>>>>>>> instructions and a
> >>>>>>>
> >>>>>>>> link for installing XQuartz. I'd do this myself in the Rcmdr
> >>>>>>>>>>
> >>>>>>>>> package if I
> >>>>>>>
> >>>>>>>> could. Or tcltk could check for the presence of X11 and not try to
> >>>>>>>>>>
> >>>>>>>>> start it
> >>>>>>>
> >>>>>>>> if it's absent, reporting a warning rather than throwing an error.
> >>>>>>>>>>
> >>>>>>>>>> Alternatively, I'd be grateful if someone could suggest how I might
> >>>>>>>>>>
> >>>>>>>>> detect
> >>>>>>>
> >>>>>>>> the problem in the Rcmdr package before loading fails. The only
> >>>>>>>>>>
> >>>>>>>>> thing that I
> >>>>>>>
> >>>>>>>> could think of was writing a separate RcmdrInstall package that
> >>>>>>>>>>
> >>>>>>>>> bypasses
> >>>>>>>
> >>>>>>>> tcltk, but that would be awkward and would only help users who
> >>>>>>>>>>
> >>>>>>>>> discovered
> >>>>>>>
> >>>>>>>> that RcmdrInstall exists.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> John
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> John,
> >>>>>>>>>
> >>>>>>>>> Is there someplace in your startup process where you could run code
> >>>>>>>>>
> >>>>>>>> along the lines of:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> if (grepl("apple", R.version$platform) &
> >>>>>>>>>
> >>>>>>>> length(list.files("/opt/X11/bin", pattern = "Xquartz")) == 0) {
> >>>>>>>
> >>>>>>>>    cat("X11 is required. Please visit http://xquartz.macosforge.org
> >>>>>>>>>
> >>>>>>>> to download and install Xquartz.")
> >>>>>>>
> >>>>>>>>    stop()
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The above code will check to see if the user is running R on OS X
> >>>>>>>>>
> >>>>>>>> and also if the Xquartz binary is present in the default location.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> Not sure if this is helpful.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> A possible correction in the above code relative to detecting OS X:
> >>>>>>>>
> >>>>>>>> if ((Sys.info()["sysname"] == "Darwin") &
> >>>>>>>>
> >>>>>>> length(list.files("/opt/X11/bin", pattern = "Xquartz")) == 0) {
> >>>>>>>
> >>>>>>>>    cat("X11 is required. Please visit http://xquartz.macosforge.org
> >>>>>>>>
> >>>>>>> to download and install Xquartz.")
> >>>>>>>
> >>>>>>>>    stop()
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I believe that Sys.info()["sysname"] == "Darwin" is preferred for
> >>>>>>>>
> >>>>>>> detecting the OS that R is running on versus the OS that it was built
> >>>>>>> upon according to the help files, if I read correctly. This could be
> >>>>>>> important if someone is building R from source versus installing
> >>>>>>> Simon's CRAN binary, I presume.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Marc
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> R-SIG-Mac mailing list
> >>>>>>>> R-SIG-Mac at r-project.org
> >>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>> _______________________________________________
> >>> R-SIG-Mac mailing list
> >>> R-SIG-Mac at r-project.org
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>>
> >>>
> >>
> >> --
> >> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> >> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> >> University of Oxford,             Tel:  +44 1865 272861 (self)
> >> 1 South Parks Road,                     +44 1865 272866 (PA)
> >> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> >>
> >>
> >> _______________________________________________
> >> R-SIG-Mac mailing list
> >> R-SIG-Mac at r-project.org
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-SIG-Mac mailing list
> > R-SIG-Mac at r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
>

More information about the R-SIG-Mac mailing list