"$ brew reinstall calculix-ccx -build-from-source" in one's own machine with new gcc version.Provide new package in brewsci/science tap, However it has anounced no maintainace anymore.I think this hack solution is temporary, because this problem should be solved more elegantly by: It worked, and I got the colored FEM results finally. Referenced from: /usr/local/opt/arpack/libexec/lib/libarpack.2.dylib I’m much happier when I find something like Postgres.app, which encapsulates all of PostgreSQL into a downloadable Mac app, and behaves like a Mac app, not a Unix tool with a complex dependency and installation chain.Dyld: Library not loaded: /usr/local/opt/gcc/lib/gcc/7/libgfortran.4.dylibĭyld: Library not loaded: /usr/local/opt/gcc/lib/gcc/8/libgfortran.5.dylib But when you hit it…then what? (I got lucky, my work laptop was due for replacement shortly after my complex toolset fell apart this Fall, so I got to start over with a clean slate…) Three tools? Twenty? Hard to predict when you hit the wall. If you’re stitching together a dozen different two-year-old blog posts covering different tools, without really understanding them, and expecting it to be problem free…you’re probably going to be disappointed at some point. In the end, you sort of need to be a bit of an expert in this area if you’re going to maintain a complex set of non-default tools. And it’s what people are often using when they document how to do something that requires compiled code. When things all work, which is most of the time, Homebrew is a bit easier. On the other hand, I’ve had reasonable success with Homebrew recently (used at work)…right up until things got too complex. And I find some of the reportedly autocratic behavior of project maintainers on Homebrew to be a bit troubling. On the one hand, I prefer the more conservative approach. Both can be fragile in the face of operating system upgrades, and even updates, but they are fragile in different ways. But MacPorts seems to take a safer, more conservative approach, installing all of its own dependencies. Homebrew is certainly the “cool kid” right now, and is faster to install most things because for dependencies it re-uses tools and libraries pre-installed on macOS. There are trade-offs between the two approaches and projects, and you might naturally gravitate to one or the other. My take-away was that Homebrew is hipster, and MacPorts is old school. There’s an extensive follow-up discussion on Hacker News, for those who want to dive deep: Just make sure you set your $PATH to point to the one you want to use. Homebrew uses /usr/local/ and MacPorts “famously” does not (it uses /opt/local/ instead). I’ve never run into any issues with Homebrew not having something I wanted (at least not that I can remember) but if you drift into the more-obscure, you might find MacPorts a better option. That being said, I believe that MacPorts still has many more packages than Homebrew. I’m not sure why that is, but Homebrew has caught the collective Mac Nerd Eye, and MacPorts has not. Whenever this discussion comes up, MacPorts is usually dismissed out of hand. I do not know if MacPorts supports M1 natively yet. Even MacPorts calls it a “legacy platform” but it still works for the few things I need.) (Ironically, I just installed MacPorts today on my iMac, because it’s running El Capitan, and Homebrew no longer works on El Capitan - which I can’t really blame them for, it’s very old. They have also said they will make it easy to change over to M1 once support is available. I have been running Homebrew under Rosetta without issue. M1 support is hopefully coming “soon” but no value of “soon” has been given or suggested. Homebrew does not yet support M1 hardware at all, and they are currently recommending that you run Terminal.app under Rosetta if using Homebrew on an M1 Mac.
0 Comments
Leave a Reply. |