[R-SIG-Mac] Mac OS X tcltk/X11 issues
Prof Brian Ripley
ripley at stats.ox.ac.uk
Thu Jul 17 11:40:06 CEST 2014
For the record, if you have package tcltk loaded you can ask it which
windowing system Tk uses by
tclvalue(.Tcl("tk windowingsystem")) # "x11" or "aqua"
However, if you want to find out which it was compiled against before
loading it, you need to do the sort of thing below.
R-patched and R-devel now have (see NEWS)
• (OS X only.) Package tcltk checks if it is linked against the
CRAN X11-based Tcl/Tk and if so that the Tcl/Tk component and the
X11 libraries are installed. This allows more informative error
messages to be given.
On 15/07/2014 15:16, Prof Brian Ripley 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
More information about the R-SIG-Mac
mailing list