Hello, I am trying to install SNAC on a MacOS device but it seems that the Clang compiler is running into problems when running make. In particular, I think a lot of files are missing #include <stdlib.h> that Clang is strict on requiring at compilation. Additionally, there are some .so files that Clang refuses to link. Any help would be appreciated!
@eitanrapa I’m not entirely sure who on this forum can help with SNAC questions. But to your two issues:
- It would of course be great if you could write a patch for GitHub - geodynamics/snac: SNAC (StGermaiN Analysis of Continua) is an updated Lagrangian explicit finite difference code for modeling a finitely deforming elasto-visco-plastic solid in 3D. in which you add the missing
<stdlib.h>header includes. I see that both @echoi2 and @gassmoeller have merged patches, and I imagine a patch that adds necessary header includes would be pretty uncontroversial. - Regarding the link issues, can you post the error messages? It’s hard to diagnose problems without knowing what the actual problems are

Best
WB
Hi WB,
Thank you for your response. I can definitely write a patch with the header includes. For the linking issue, this is my error:
ld: unsupported mach-o filetype (only MH_OBJECT and MH_DYLIB can be linked) in ‘/Users/erapaportbruck/Documents/GitHub/snac/build/lib/SnacTemperaturemodule.so’
clang: error: linker command failed with exit code 1 (use -v to see invocation)
@eitanrapa I must admit that I don’t know what the error message is trying to say. I believe that on Mac OS X, shared libraries are generally named .dylib instead of .so. It is possible that the makefiles for SNAC were simply never meant to be used on Mac and have only ever been tested on Linux – i.e., they hard-code things that are Linux-specific, including file endings. The files in the repository have not been touched in 17 years, so that actually sounds quite likely to me. But then I wouldn’t know for sure. You might have to work yourself through the Makefiles of SNAC to find the place where the .so library is built ![]()
The “right” solution would of course be to replace the hand-written configuration and build system by something more modern – specifically by something that uses CMake. For someone who knows CMake, I suspect that wouldn’t be an incredible amount of work (perhaps 1-2 days), but the number of people who are proficient with CMake is not huge, and so that might be quite a lot of work for you. (That’s the kind of thing for which AI might actually be quite good at, though, given that there are many many existing examples out there – who knows.)
Best
WB
@eitanrapa SNAC is not maintained anymore… If you have a burning reason to run SNAC on your mac, how about taking the Docker route? A Docker file has been recently added.
@echoi2 Thank you for your response. I will try the Docker route, and if that doesn’t work I can just try installing it on a Linux machine.
@bangerth I do have some experience with another C builder (mm), but since SNAC is no longer maintained perhaps it is not worth fixing.
@eitanrapa, you’re welcome and good luck!
BTW, I presume what you would like to try is a certain functionality of SNAC, not SNAC itself. If that’s the case, you might want to take a look at GitHub - GeoFLAC/DynEarthSol: Dynamic Earth Solver, a standard finite element transplant of geoflac for unstructured meshes with P1 elements in 2D and 3D. DynEarthSol implements the same solution algorithm with SNAC and provides the same set of rheologies.
Hi @echoi2, I wasn’t aware of that code, thank you for recommending it. I see that DynEarthSol is a finite element code instead of a finite difference code like SNAC. I am interested in modeling how faults initiate and evolve naturally from constitutive laws without prescribing geometry, and so my main motivation for trying SNAC is that in my understanding, the finite difference aspect helps avoid the remeshing problems I might encounter with an FEM. I really appreciate your opinion! And thanks for developing these tools for us.
Good to know more about what you would like to work on!
how faults initiate and evolve naturally from constitutive laws without prescribing geometry
The family of FLAC-based codes including SNAC and DynEarthSol have been extensively used for this type of problem. Please feel free to leave a problem description on the DynEarthSol’s GitHub issue tracker and ask for further guidance to get started with it.
As you pointed out, DynEarthSol still needs remeshing. But in that regard, so does SNAC: It’s technically finite difference but essentially Lagrangian finite element.
Finally, you would want to check out ASPECT as well. The strain weakening rheology it has might be suitable for your problem about fault initiation and evolution.
Great! That makes sense. Thanks again.