X11 supported R builds will likely be deprecated in the future

[sethrfore]

I wanted to start a discussion surrounding the ongoing support of R/X11 dependencies. The vast majority of issues I've dealt with while maintaining this repository have related to X11 either with respect to Cairo or Tcl-Tk. While not all issues have been terribly difficult to solve, there are a variety of considerations that have caused me (personally) to reconsider providing ongoing X11 support in the future.

Homebrew-core has opted to increasingly restrict core formula compiling options to facilitate a more streamlined and dependable work-flow. While I can fully appreciate this decision, a side effect has been that upstream R dependencies are increasingly bottled with options that are incompatible with certain R functionalities. Solving this requires creating and maintaining alternate versions of formulas with different compiling options than those supported in the core version.

If this issue were only restricted to first level dependencies, that would be one thing. However, it is increasingly not this simple. In some cases the build options for dependencies 3 or 4 levels removed from R are the source of issues requiring not just one new formula but new formulae for the entire chain of dependencies to ensure other packages build correctly. I suspect this will become an increasing challenge as core formulae become less flexible with their compiling options. Moreover, all these issues are compounded by ongoing changes to Xcode and Command Line Tools.

I know many of the issues that may arise could be quickly and easily addressed by someone with greater experience than I; however, I am not a developer by training and do not always have the time available to solve them. While I've been willing for and enjoyed most the work required to maintain all this in the past, the increasing complexity and time requirement has made me question my time allocation.

In conclusion, I'm not planning on deprecating R/X11 immediately, but unless others want to contribute and provide pull requests for issues, I'll likely only fix issues that are very quickly solved.

If issues arise that break R/X11 builds and they remain unaddressed, that's when I'll provide a notice and formally deprecate R/X11 support.

Having said all that, for whomever reads this, I will continue supporting a non-X11 R formula that offers greater functionality than the Homebrew-core version. Thanks to those that have contributed to maintaining this repo and feel free to provide your feedback or comments.

[luispuerto]

Hey @sethrfore!!

First of all, thanks a lot for your work and for this tap. It's been really useful.

This is more or less the same case as with the QGIS tap… the dependencies that needed fine tuning were mounting and maintenance was really difficult.

I'm using your tap mainly because I wanted to use the openblas library, but I really don't know if this also worth it. I'm really thinking to return to the R binary provided by "casks" and finish with this.

[sethrfore]

On second though, it may not matter... If you symlink openblas to /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib, any package with that reference will just route through your openblas library instead of the standard one. I really doubt you'll have any issues using a symlinked openblas in that manner.

[luispuerto]

Besides the issues … I would like to know if the benchmarks are going to be the same as if you build R --with-openblas. If that's the case… building R, IMHO, doesn't have sense, at least on the "operational basics". Specially due to the hassle you've pointed out about dependencies and custom build dependencies.

[yukio-takeuchi]

I would like to thank for your effort. I was thinking of possibility of compiling tcl-tk with X11 for R, whenever I saw the warnings about deprecation of system tcl-tk recently. But I could not figure out how to compile tcl-tk with X. It it really great effort.

I have one suggestion to consider add revision tag in the formula like

revision 1

1 can be incremented whenever formula is updated although version remain same.
This indicates, even if "version" in formula is 4.0.3, "version" we can see brew info is updated from 4.0.3 to 4.0.3_1. This may help user to update R installed by this formula as brew upgrade wiii upgrade it if version is "incremented" from 4.0.3 to 4.0.3_1.

By the way I have a similar question on opnblas
I reinstalled this formula by following command

brew install -s sethrfore/r-srf/r --with-openblas --with-cairo-x11 --with-icu4c --with-libtiff  --with-openjdk --with-tcl-tk-x11 --with-texinfo

It finished .

Then, in /usr/local/Cellar/r/4.0.3/lib/R/lib/ I can only find

❯ ls -lh /usr/local/Cellar/r/4.0.3/lib/R/lib/
total 5176
-r--r--r--  1 yukiot  admin   2.5M  1 26 08:10 libR.dylib

Can you advise me in "/usr/local/Cellar/r/4.0.3/lib/R/lib/" what files should exit, if this formula is installed with the option "--with-openblas"?

[yukio-takeuchi]

As a self follow up, I realized R, which I installed, uses openblas as

> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-apple-darwin20.2.0 (64-bit)
Running under: macOS  11.1

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.13/lib/libopenblasp-r0.3.13.dylib

locale:
[1] ja_JP.UTF-8/ja_JP.UTF-8/ja_JP.UTF-8/C/ja_JP.UTF-8/ja_JP.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.3

So please allow me to revise my question.
If this formula is installed with --with-openblas,
what files should exists in "/usr/local/Cellar/r/4.0.3/lib/R/lib/"
In the past I suspect e.g. libRblas.dylib was there.

[sethrfore]

But I could not figure out how to compile tcl-tk with X.

Installing R from the master branch using the --with-tcl-tk-x11 option should install an X11 based version of tcl-tk. While I'm not completely sure, it may still be necessary to have xquartz installed. Sometimes xquartz gets messed up with OS updates and needs to be reinstalled. Try reinstalling xquartz, cairo-x11, and tcl-tk-x11 and then recompile R.

With regard to openblas, this portion of your sessionInfo output is the same as mine.

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.13/lib/libopenblasp-r0.3.13.dylib

This would suggest things are installed properly give your selected compiling options. As a sanity check, open R in a terminal window and after its running open another terminal window and run ps -a -x -o pid,comm | grep exec/R | awk {'print$1'} | xargs lsof -p | grep 'blas\|lapack'. This will show you the currently active blas/lapack versions. My output looks like this:

❯ ps -a -x -o pid,comm | grep exec/R | awk {'print$1'} | xargs lsof -p | grep 'blas\|lapack'
R       52683 SethRFore  txt    REG    1,5 61547424         12945218239 /usr/local/Cellar/openblas/0.3.13/lib/libopenblasp-r0.3.13.dylib

If this is what you see, then things are correctly installed based on your selected compiling options. If this is not what you see, try uninstalling R and reinstall all R dependencies via brew deps -n sethrfore/r-srf/r | xargs brew reinstall and reinstall R again and check again.

I have one suggestion to consider add revision tag in the formula

Good idea, I'll start doing that.

[luispuerto]

Another stupid question… Isn't the R binary accesible from the terminal? or do you need to link it?

[sethrfore]

Yes, the R and Rscript executables are accessible in terminal.

[luispuerto]

I don't know why… but those two aren't on /usr/local/bin/ when I install the binary from brew cask

[sethrfore]

I don't know why… but those two aren't on /usr/local/bin/ when I install the binary from brew cask

You're right about this, at least as far as the Homebrew cask R installation. They used to be linked. There are even instructions to delete /usr/bin/R and /usr/bin/Rscript in the formula uninstall stanza. I guess I dunno what's up with that...

[luispuerto]

You can run command-line R and Rscript from a Terminal^21 so these can be typed as commands like any other Unix-alike: see the next chapter of this manual.

21: The installer puts links to R and Rscript in /usr/local/bin. If these are missing, you can run directly the copies in /Library/Frameworks/R.framework/Resources/.

source: https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Running-R-under-macOS

I do know now… they are aware of the problem on Big Sur and they don't know why is happening.

[asam46]

Hi, @sethrfore!

I find the problem when running the functions related to x11, for example

r$> View(iris)
Error in .External2(C_dataviewer, x, title) : unable to start data viewer
In addition: Warning messages:
1: In View(iris) :
  locale not supported by Xlib: some X ops will operate in C locale
2: In View(iris) : X cannot set locale modifiers
3: In View(iris) :
  unable to create fontset -*-fixed-medium-r-*-*-*-120-*-*-*-*-*-*

I follow your instructions to install R and actually I find in capabilities()

r$> capabilities()
       jpeg         png        tiff       tcltk         X11        aqua
       TRUE        TRUE        TRUE        TRUE        TRUE        TRUE
   http/ftp     sockets      libxml        fifo      cledit       iconv
       TRUE        TRUE        TRUE        TRUE       FALSE        TRUE
        NLS     profmem       cairo         ICU long.double     libcurl
       TRUE        TRUE        TRUE        TRUE        TRUE        TRUE

However, in terms of such weird error I cannot find the proper solutions. Could you please help? Well, actually I am totally fine with current settings, but I am just sort of curious about such errors. BTW, what are the bad outcomes without x11 supported in R?

r$> sessionInfo()
R version 4.0.4 (2021-02-15)
Platform: x86_64-apple-darwin20.3.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.13/lib/libopenblasp-r0.3.13.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.4 tools_4.0.4

[FirasSadiyah]

@asam46 This error is due to locale. You need LC_CTYPE=C.
From within R, you can do: Sys.setlocale("LC_CTYPE","C")

[asam46]

@FirasSadiyah Wow, thanks so much! The problem is solved!

[jd-a]

I tried to version bump R to 4.2.2 on macOS 13 with the CLT 14.1 and XQuartz 2.8.2. the build fails: with the following message:
devQuartz.c:710:35: error: 'ATSFontFindFromName' is unavailable
atsFont = ATSFontFindFromName(cfFontName, kATSOptionFlagsDefault);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATSFont.h:811:1: note: 'ATSFontFindFromName' has been explicitly marked unavailable here
ATSFontFindFromName(

[yukio-takeuchi]

I also met the same error with the original formula, whose R version is 4.2.1. Also the same error happened with homebrew's official R formula with R 4.2.2 on macOS 13 with CLT 14.1. I suspect, we need to wait for R develop team to fix this.

[jd-a]

I just set the macOS SDK to use for the homebrew build environment to 12. R builds then, but I have not done extensive testing....

[sethrfore]

Same problems here. Based on this conversation, these errors result from upstream decisions made by Apple:

macOS 13 is the last release where code depending on ATS or ATSUI will run. All runtime functionality will be removed in next major release of macOS.

A more permanent solution will have to be implemented in the R dev space, or so it seems...

In the time being, I've merged a pull request manually pointing to macOSX12.sdk proposed by @jd-a in #56.

FYI - As future problems arise, please open a new issue on GitHub. This will keep our conversation threads more focused and make tracking the development of issues and and their solutions easier. Thanks for everyones feedback.

[jd-a]

Looks like for R version 4.3.0 everything works again without changing the SDK version.

[ocsmit]

Wanted to echo this with the note that compiling from source w/ 4.1.1 failed on a clean Mac installation for me with the same ATSFontFindFromNameerror, but that 4.3.0 source compiles no problem.

[sethrfore]

Implemented version bump and removed ATS Font patch from master branch. Thanks.