Bob ran into problems compiling stan_math on his new MacBook pro - which he blogged about here:
https://statmodeling.stat.columbia.edu/2019/12/11/macbook-pro-16-inch-2019-quick-review/
Ease of upgrade
Apple makes it super easy to move everything from an old machine. Once I entered enough passwords on my menagerie of Apple devices, it took less than 2 hours to transfer everything from the old machine to the new one via my home wireless network.
The only software I’ve had to upgrade to get back to working on Stan is Xcode (the C++ compiler). And I did that just from the command line using this one-liner:
xcode-select --install
Hats off to Dirk Avery for his blog post on Catalina, Xcode, and Homebrew.
It really was that easy. The entire Stan developer toolchain just works. R, RStan, etc., all just ran once I ran the above command from the terminal.
but he ran into problems compiling - mentioned here: Fully functional std::complex specializations and overloads - #47 by Bob_Carpenter
at the point where the makefile tries to compile sundials, it fails with error
“ar: internal ranlib command failed”
the culprit was the installed versions of ranlib
, ar
, and ld
in /opt/local/usr/bin
. hiding or removing these allowed make to pick up the versions in usr/bin
which work for clang and xcode.
as Bob noted, he migrated over everything from his old machine, including whatever got installed by macports and homebrew over the past 5+(?) years. I tried following the suggestion in Dirk Avery’s blog regarding homebrew:
Homebrew errors
Homebrew (“Brew”) per se did not have issues after the Catalina upgrade. However, some packages delivered through formulae and casks have not been updated for Catalina and are stuck back in Mojave (or High Sierra, eek!). Old packages will likely have issues with Catalina since a lot has changed.
following his “elephant gun” suggestion, I ran:
for x in brew list do brew reinstall $x; done
(note, backticks around brew list
in above command swallowed by discourse formatter)
this didn’t seem to help, at which point I:
- brute force removed
/opt/local/usr/bin/ranlib
(tired and desperate move - should have hid it instead) - renamed
/opt/local/usr/bin/ar
to/opt/local/usr/bin/ar.hide
and/opt/local/usr/bin/ld
to/opt/local/usr/bin/ld.hide
.
now make
picks up the /usr/bin
versions.
this seems like a massive hack - perhaps a devops guru can advise?
is /opt/local/usr/bin
an artifact from macports
and should it be removed altogether, and the $PATH variable updated accordingly?