Upgrade to Catalina incurred problems building math lib dynamic archives (sundials)

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

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?

to answer my own question, these problems are all due to an old install of MacPorts.
removing the MacPorts install dir /opt/local/bin from the path solved the problem.
Bob still needs to get rid of MacPorts from his machine - the uninstall process doesn’t work as advertised.

bottom line: avoid MacPorts, use Homebrew whenever possible.