gfortran cask duplicates the gcc formula in homebrew-core

[fxcoudert]

I discovered today that there is a gfortran cask, which is distributing the gfortran installers that I build and make available. It's been happening for 3 years and I never knew 😄

I don't think that it fits the homebrew-cask rules, though:

• despite their name, these installers are a full GCC install, not just gfortran
• gfortran is fully part of GCC and cannot be separated, anyway
• this is purely command-line software
• that is already available as the gcc formula in homebrew-core

I could understand if the two distributions were different, but as I'm basically maintaining both, I don't think it should be kept that way. I suggest the cask be removed and users redirected to the gcc formula.

[elbamos]

Could there be a difference between how this gets linked and how the gcc package does? My expectation using it was that it was "just" gfortran without gcc, that it put gfortran into my PATH, for things that depend on gfortran to find (i.e., R), but didnt otherwise muck up the path with lots of gcc stuff that would interfere with the Apple toolchain.

[miccal]

It is a reasonably popular Cask, though:

|-> brew info gfortran
gfortran: 10.2
https://gcc.gnu.org/wiki/GFortranBinaries
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/gfortran.rb
==> Name
gfortran
==> Description
GNU Fortran packages
==> Artifacts
gfortran.pkg (Pkg)
==> Caveats
Cask gfortran installs files under /usr/local. The presence of such
files can cause warnings when running `brew doctor`, which is considered
to be a bug in Homebrew Cask.

==> Analytics
install: 1,644 (30 days), 4,549 (90 days), 10,812 (365 days)

[fxcoudert]

It is a reasonably popular Cask

Not as much as the gcc formula :)

==> Analytics
install: 77,153 (30 days), 257,586 (90 days), 1,190,039 (365 days)
install-on-request: 36,240 (30 days), 119,004 (90 days), 564,291 (365 days)
build-error: 0 (30 days)

[fxcoudert]

didnt otherwise muck up the path with lots of gcc stuff that would interfere with the Apple toolchain

The gcc formula is careful with that, too. All binaries are suffixed with the version number (e.g., gcc-10) so they don't interfere. All, except gfortran:

$ ls /usr/local/opt/gcc/bin 
c++-10                              gcc-nm-10                           gfortran                            x86_64-apple-darwin20-gcc-10        x86_64-apple-darwin20-gfortran-10
cpp-10                              gcc-ranlib-10                       gfortran-10                         x86_64-apple-darwin20-gcc-10.2.0
g++-10                              gcov-10                             lto-dump-10                         x86_64-apple-darwin20-gcc-ar-10
gcc-10                              gcov-dump-10                        x86_64-apple-darwin20-c++-10        x86_64-apple-darwin20-gcc-nm-10
gcc-ar-10                           gcov-tool-10                        x86_64-apple-darwin20-g++-10        x86_64-apple-darwin20-gcc-ranlib-10

[fxcoudert]

As I said, I don't really see a reason one would want to install the cask over the formula. The reason I provide these standalone installers is only for some colleagues who want to have a gfortran install and don't know / don't want to learn how to install homebrew: the installer is a nice click-through.

I would highly recommend people who have brew installed to actually use the formula: it is more up-to-date, as well, and consistently provides the latest version of gfortran. If you look at the cask, you'll see it provides:

• nothing on Big Sur
• 10.2 on Catalina
• 8.2 on Mojave

[carlocab]

for some colleagues

==> Analytics
install: 1,644 (30 days), 4,549 (90 days), 10,812 (365 days)

You have plenty of colleagues.

On a more serious note, I don't see a reason why there should be a gfortran cask. Perhaps the best thing to do would be to:

1. Remove gfortran from homebrew-cask
2. Add "gfortran": "homebrew/core" to tap_migrations.json
3. Add an alias gfortran -> ../Formula/gcc.rb at homebrew-core

I think that should smooth the transition for everyone still using the cask, unless I've misunderstood how all of this works. (That's certainly possible.)

Happy to open the necessary PRs if that solution works.

[fxcoudert]

@carlocab sounds good to me

[carlocab]

PRs opened:

#96504
Homebrew/homebrew-core#67387

[imrehorvath]

Hello! This change breaks compatibility with R CRAN source packages with fortran linkage, since they rely on the location /usr/local/gfortran. The gfortran Cask with the .pkg in it installed gfortran to that location. Simply aliasing gfortran to gcc does not provide the same setup as the Cask did.

[carlocab]

Does changing /usr/local/gfortran to /usr/local/opt/gcc not work?

Otherwise, you can maintain a tap for the gfortran cask. However, this creates duplicate installations for anyone who also has the gcc formula installed, so it really would be better to use the gcc formula instead. Note that the gfortran cask does not support Big Sur.

[liuyadong]

@imrehorvath @carlocab It works by adding two lines to the .r/Makevars:

FC = /usr/local/opt/gcc/bin/gfortran
FLIBS = -L/usr/local/opt/gcc/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -lm

[carlocab]

Thanks @liuyadong! You can also shorten

-L/usr/local/opt/gcc/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0

to

-L/usr/local/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0

It's not that much shorter, but you might prefer the more standard /usr/local/lib.

[liuyadong]

@carlocab Of course! btw there is a typo, 20 -> 19 😄

[imrehorvath]

Thank you both! @carlocab @liuyadong
Works great! 👍
Now my .r/Makevars looks like this:

FC = /usr/local/bin/gfortran
FLIBS = -L/usr/local/lib/gcc/10 -lgfortran -lquadmath -lm

[NathanSkene]

Hi all,

we've been discussing this in a related issue: Homebrew/discussions#422 (reply in thread)

I'd been unable to get pkgbuild::check_build_tools(debug = TRUE) to work after upgrading to bigSur. Eventually I installed @fxcoudert's package, following a suggestion to do so here. Using that Makevars suggested on that page, R now started working properly.

I tried setting the R Makevars to those suggested in this thread, and still cannot use devtools

That is, I've set Makevars to:

FC = /usr/local/bin/gfortran
FLIBS = -L/usr/local/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0 -lm

And I then get:

> pkgbuild::check_build_tools(debug = TRUE)
Trying to compile a simple C file
Running /Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB foo.c
clang -mmacosx-version-min=10.13 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   -I/usr/local/include   -fPIC  -Wall -g -O2  -c foo.c -o foo.o
clang -mmacosx-version-min=10.13 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o foo.so foo.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
ld: framework not found CoreFoundation
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [foo.so] Error 1
Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.

Prior to this my Makevars had been:

FLIBS=-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin20/10.2.0 -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
CXX1X=/usr/local/gfortran/bin/g++
CXX98=/usr/local/gfortran/bin/g++
CXX11=/usr/local/gfortran/bin/g++
CXX14=/usr/local/gfortran/bin/g++
CXX17=/usr/local/gfortran/bin/g++

LLVM_LOC = /usr/local/opt/llvm
CC=/usr/local/gfortran/bin/gcc -fopenmp
CXX=/usr/local/gfortran/bin/g++ -fopenmp
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe
LDFLAGS=-L/usr/local/opt/gettext/lib -L$(LLVM_LOC)/lib -Wl,-rpath,$(LLVM_LOC)/lib
CPPFLAGS=-I/usr/local/opt/gettext/include -I$(LLVM_LOC)/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include

Any suggestions on what the ideal solution to this is? I suspect a lot of people will be having this issue if it's a general problem relating to bigSur and R.

[liuyadong]

It works well on my machine using brew gcc and system compiler, just setting Makevars:

CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lomp

FC = /usr/local/bin/gfortran
FLIBS = -L/usr/local/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0 -L/usr/local/lib/gcc/10 -lgfortran -lquadmath -lm

[NathanSkene]

Thanks for suggesting. Just tried setting that as my Makevars and doesn't work on my system, got the following errors:

pkgbuild::check_build_tools(debug = TRUE)

Trying to compile a simple C file
Running /Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB foo.c
clang -mmacosx-version-min=10.13 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   -I/usr/local/include -Xclang -fopenmp   -fPIC  -Wall -g -O2  -c foo.c -o foo.o
clang -mmacosx-version-min=10.13 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -lomp -o foo.so foo.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
ld: framework not found CoreFoundation
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [foo.so] Error 1
Error: Could not find tools necessary to compile a package
Call `pkgbuild::check_build_tools(debug = TRUE)` to diagnose the problem.

[elbamos]

Editing the Makevars is something of an unsolution. One of the advances in R OS X 4.0 is you don’t have to edit the makevars anymore. Once you start editing them, you can easily get into a situation where things you compile don’t link properly with binary downloads.

A better solution is to just download and install gfortran. A few mb of duplicated data isn’t problematic. This is what the cask did.

The former cask could easily have been updated to support arm (which r doesn’t support yet anyway) by pointing at fxcoudert’s latest.

btw - since we’re talking about R-homebrew compatibility, the decision by homebrew to release arch-specific rather than universal library binaries is going to make transitioning a mess. When r comes out with arm64 support, to use it with r packages, homebrew users will have to switch their whole brew installation to arm64, which is then going to break their r x86 installations.

[fxcoudert]

homebrew users will have to switch their whole brew installation to arm64, which is then going to break their r x86 installations

We made design decisions that mean it's totally possible to have two Homebrew installs on Apple Silicon, one ARM (in /opt/homebrew) and one Intel for Rosetta 2 (in /usr/local)

[elbamos]

homebrew users will have to switch their whole brew installation to arm64, which is then going to break their r x86 installations

We made design decisions that mean it's totally possible to have two Homebrew installs on Apple Silicon, one ARM (in /opt/homebrew) and one Intel for Rosetta 2 (in /usr/local)

R packages are sometimes delivered as source and sometimes as binaries. R has its own internal system for finding its toolchain and libraries, for building packages from source. When the local installation desynchronizes from the toolchain used to compile the binary packages (i.e., by changing Makevars), local administration can become challenging.

When there is a stable dev version of R arm64 (which I expect to be this week), and there are also instructions for setting up parallel homebrew installations that don't interfere with each other and migrating from one to the other, I would be happy to try out whether it is possible to setup R with homebrew in the way you propose.

[NathanSkene]

Editing the Makevars is something of an unsolution. One of the advances in R OS X 4.0 is you don’t have to edit the makevars anymore. Once you start editing them, you can easily get into a situation where things you compile don’t link properly with binary downloads.

A better solution is to just download and install gfortran. A few mb of duplicated data isn’t problematic. This is what the cask did.

The former cask could easily have been updated to support arm (which r doesn’t support yet anyway) by pointing at fxcoudert’s latest.

btw - since we’re talking about R-homebrew compatibility, the decision by homebrew to release arch-specific rather than universal library binaries is going to make transitioning a mess. When r comes out with arm64 support, to use it with r packages, homebrew users will have to switch their whole brew installation to arm64, which is then going to break their r x86 installations.

Interesting to hear! This is probably drifting more into R than Homebrew territory, but if I leave my Makevars empty, then when I run pkgbuild::check_build_tools(debug = TRUE) I get the ld: framework not found CoreFoundation error. So it looks like R 4.x does still need a Makevars file. Perhaps this should be flagged as an issue at the R issues page.

[elbamos]

@NathanSkene That shouldn't happen, and doesn't happen on my system. Perhaps you are using the homebrew R formula instead of R from CRAN? You really want to use the CRAN one instead of the homebrew one - its compiled with the full set of capabilities(), when you install a new major version it doesn't wipe out your prior versions, it works properly with binary downloads from CRAN, etc.

@fxcoudert The R Mac OS X folks posted a working R-arm64 build this morning. I'm now attempting the dual-homebrew/R setup you proposed. As expected, the split library paths do create a problem, because the R toolchain expects libraries and pkgconfig to be found under /usr. It may be possible to find a Makevars formula that makes it all work (so far my attempts have been unsuccessful). But Makevars is set at the user level rather than the R-installation level, so doing so will affect the user's x86_64 installation as well. If you have an interest in the outcome here, let me know and I'll post additional information as I find it.

[NathanSkene]

Afraid it is the CRAN version of R that I'm using

…

On Mon, 4 Jan 2021, 18:47 elbamos, ***@***.***> wrote: This email from ***@***.*** originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address. @NathanSkene <https://github.com/NathanSkene> That shouldn't happen, and doesn't happen on my system. Perhaps you are using the homebrew R formula instead of R from CRAN? You really want to use the CRAN one instead of the homebrew one - its compiled with the full set of capabilities(), when you install a new major version it doesn't wipe out your prior versions, it works properly with binary downloads from CRAN, etc. @fxcoudert <https://github.com/fxcoudert> The R Mac OS X folks posted a working R-arm64 build this morning. I'm now attempting the dual-homebrew/R setup you proposed. As expected, the split library paths do create a problem, because the R toolchain expects libraries and pkgconfig to be found under /usr. It may be possible to find a Makevars formula that makes it all work (so far my attempts have been unsuccessful). But Makevars is set at the user level rather than the R-installation level, so doing so will affect the user's x86_64 installation as well. If you have an interest in the outcome here, let me know and I'll post additional information as I find it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5ZPEZCF7TM4QCQ7QULHALSYIEM5ANCNFSM4VDNG7PQ> .

[fxcoudert]

the R toolchain expects libraries and pkgconfig to be found under /usr

I would suggest to change that, make it configurable.

If you have an interest in the outcome here

I'm not an R user myself, just trying to get things in the best shape for others.