I installed GetFEM 5.4.2 both on my MacBook Pro Intel and on my iMac (ARM CPU, M1), but in both cases I get the following error when I run ./configure:
you are compiling GetFEM on a arm-apple-darwin23.6.0
Using the GNU g++ compiler version
checking whether g++ accepts -O3... no
checking whether g++ accepts -fmessage-length=0... no
checking whether g++ accepts -fvisibility-inlines-hidden... no
checking whether g++ accepts -ftemplate-depth-100... no
checking whether g++ accepts -std=c++14... no
checking whether g++ accepts -std=c++0x... no
configure: error: g++ do not support option -std=c++14. Update g++ to at least release 4.9
How to fix this? When I run g++ --version I get
Apple clang version 16.0.0 (clang-1600.0.26.4)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
hi, this does not look like g++. It seems that clang on your system pretends to be g++, which is is not a very good idea. Anyway, to circumvent this problem of your system, you can tell explicitly to the configure script that you want to use clang with
and everything worked well (except I had to sudo make install instead of just make install), then I made a make check and obtained this outcome:
Making check in interface
Making check in src
Making check in .
make[3]: Nothing to be done for `check-am'.
Making check in python
make[3]: Nothing to be done for `check'.
Making check in tests
Making check in meshes
make[3]: Nothing to be done for `check'.
Making check in python
/Library/Developer/CommandLineTools/usr/bin/make check-TESTS
../../../test-driver: line 107: 36838 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: check_export.py
PASS: check_export_vtu.py
../../../test-driver: line 107: 36850 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: check_global_functions.py
../../../test-driver: line 107: 36856 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: check_asm.py
../../../test-driver: line 107: 36862 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: check_secondary_domain.py
../../../test-driver: line 107: 36868 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: check_mixed_mesh.py
../../../test-driver: line 107: 36874 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_truss.py
../../../test-driver: line 107: 36880 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_wave.py
../../../test-driver: line 107: 36886 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_wave_equation.py
../../../test-driver: line 107: 36892 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_laplacian.py
../../../test-driver: line 107: 36898 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_laplacian_HHO.py
../../../test-driver: line 107: 36904 Segmentation fault: 11 "$@" > $log_file 2>&1
FAIL: demo_elasticity_HHO.py
============================================================================
Testsuite summary for getfem 5.4.2
============================================================================
**# TOTAL: 12**
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 11
# XPASS: 0
# ERROR: 0
============================================================================
See interface/tests/python/test-suite.log
============================================================================
make[5]: *** [test-suite.log] Error 1
make[4]: *** [check-TESTS] Error 2
make[3]: *** [check-am] Error 2
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1
I equally tried to run python3 demo_laplacian.py and obtained the following:
File "/Users/francescobonaldi/getfem-5.4.2/interface/tests/python/demo_laplacian.py", line 32, in <module>
import getfem as gf
ModuleNotFoundError: No module named 'getfem'
even though I tried several different versions of Python (currently I tried with 3.11 which is supposed to work)!
you need to run the script with the same python version that you compiled the module for, and you need to make sure that PYTHONPATH environment variable includes the location where the getfem.py file is.
For you to better understand what you are doing, I will give you the following overview of files involved in the process, for example for python 3.12
If you install on some no-standard locaction, python needs to have ...some/installation/directory/lib/python3.12/site-packages/getfem
When you import the module in python File #1 is imported, and this file loads File #2.
If File #2 was built with static linking, then the process finishes there.
If File #2 was built with shared library linking, then it will need to link to File #3 at run time, so your operating system linker needs to have ...some/installation/directory/lib in its search path. For example in Linux this is done with the environment variable LD_LIBRARY_PATH.
Thanks, indeed there was no getfem in the site-packages directory. I fixed it; nevertheless on running python demo_laplacian.py I get
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/getfem/getfem.py", line 45, in <module>
from ._getfem import *
ImportError: dlopen(/usr/local/lib/python3.11/site-packages/getfem/_getfem.cpython-311-darwin.so, 0x0002): symbol not found in flat namespace '_qh_qh'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/francescobonaldi/getfem-5.4.2/interface/tests/python/demo_laplacian.py", line 32, in <module>
import getfem as gf
File "/usr/local/lib/python3.11/site-packages/getfem/__init__.py", line 16, in <module>
from .getfem import *
File "/usr/local/lib/python3.11/site-packages/getfem/getfem.py", line 47, in <module>
from _getfem import *
ModuleNotFoundError: No module named '_getfem'
This is because some link dependency is not found. I suspect the qhull library.
I have no experience with Mac, but I believe this is because you used this option in your configure
--disable-dependency-tracking
I had never seen this option before, but I guess it is very bad. The entire purpose of configure is to track dependencies. I do not see the point of having an option like this.
looking into your config.log it seems that configure finds the qhull headers but not the qhull library. Actually this should result in compiling GetFEM without qhull support, but maybe we have messed up this check in the configure script. We should fix that if it is the case, but right now for your purpose, in order to get GetFEM with its full functionality, I would rather suggest that you make sure that the qhull library is available on your system and that it is actually found by the configure script.
Alternatively you can disable qhull with the --disable-qhull
configure option, but this will result in reduced functionality.
Just let me know if you need additional help with this.
Thanks, I will look into that when I use again the Intel MacBook (on which I can remove the --disable-dependency-tracking option without a problem, when running the configure script).
Now, two things occurring on the Apple Silicon (ARM) Mac:
FYI, this is the error I get if I run ./configure without the --disable-dependency-tracking option:
config.status: error: Something went wrong bootstrapping makefile fragments
for automatic dependency tracking. Try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency tracking).
See `config.log' for more details
Python is still not able to find the getfem module when typing python demo_laplacian.py, but I identified the reason of this behavior. I installed Python 3.11 as well as numpy, scipy, and matplotlib. Nevertheless, when I run ./configure, this is what it does:
checking for a Python interpreter with version >= 3.6... python
checking for python... /opt/homebrew/opt/python@3.11/libexec/bin/python
checking for python version... 3.1
checking for python platform... darwin
checking for python script directory... ${prefix}/lib/python3.1/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.1/site-packages
In other words, it identifies Python 3.1 and not Python 3.11. As a consequence, it installs the getfem folder into the site-packages directory of Python 3.1, and not that of Python 3.11.
I typed
python --version
and the result is Python 3.11.10, then I typed
which python
and the result is /opt/homebrew/opt/python@3.11/libexec/bin/python, as expected.
So, why does it find 3.1 instead of 3.11?
The right location to install the getfem folder should be
this is the macro, autoconf uses for detecting python on your system:
maybe you can find something in the documentation about which version is prioritized if there are multiple python versions on your system.
I hope that you are aware of that the development version of GetFEM supports building with cmake as well. Maybe it is easier for you to setup cmake to work with your system, if you have more experience with this build system than autoconf.
yes, or even without editing configure.ac. This is a relevant discussion from a developer’s perspective:
the accepted answer hints that you can influence what the chosen python version is by setting the PYTHON environment variable.
As a general hint, there are two viable ways of configuring your operating system for python:
only one system-wise python and no packages installed through pip (neither conda etc.)
use one separate python virtual environment for every project, and install the project specific packaged through pip (or conda or similar)
These two solutions are not exclusive, they can coexist.
In every other configuration with multiple system-wise python installations, or with pip managing your system-wise python, you will run into problems rather soon than later.
Now, autoconf detects the right version and the right path of Python.
So, this might be useful for other GetFEM users on Apple Silicon computers as well.
Nonetheless, the problem is still that the getfem directory is created by, I suppose, Makefile or something else under
/usr/local/lib/python3.11/site-packages/
and not, as I would expect, under
/opt/homebrew/lib/python3.11/site-packages.
Even the files libgetfem.5.dylib, libgetfem.a, and libgetfem.la are created under /usr/local/lib.
I see in my configure script this is already fixed. The configure script is generated by autoconf, so I guess they fixed the issue since we produced the last getfem release, so it should be automatically fixed also in GetFEM next time we do an official release.
In the same spirit of this topic, I noticed the following execution error after a make check in GetFEM 5.4.4. This is the only script failing during the make check, all other scripts, including Python ones and XFEM, are ok.
========================================
getfem 5.4.4: tests/test-suite.log
========================================
# TOTAL: 41
# PASS: 40
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
System information (uname -a): Darwin 24.2.0 Darwin Kernel Version 24.2.0: Fri Dec 6 19:03:40 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041
.. contents:: :depth: 2
FAIL: make_gmm_test.pl
======================
Gmm tests : Making 1 execution of each test
Testing ./gmm_torture01_lusolve.cc
ld: warning: -ld_classic is deprecated and will be removed in a future release
Testing ./gmm_torture02_baseop.cc
ld: warning: -ld_classic is deprecated and will be removed in a future release
Testing ./gmm_torture05_mult.cc
ld: warning: -ld_classic is deprecated and will be removed in a future release
Testing ./gmm_torture06_mat_mult.cc
ld: warning: -ld_classic is deprecated and will be removed in a future release
Testing ./gmm_torture10_qr.cc
ld: warning: -ld_classic is deprecated and will be removed in a future release
============================================
| A GMM error has been detected !!! |
============================================
Error in /opt/homebrew/include/gmm/gmm_dense_qr.h, line 786 void gmm::symmetric_qr_algorithm(const MAT1&, const VECT&, const MAT2&, typename number_traits<typename linalg_traits<V>::value_type>::magnitude_type, bool) [with MAT1 = dense_matrix<float>; VECT = std::vector<float>; MAT2 = dense_matrix<float>; typename number_traits<typename linalg_traits<V>::value_type>::magnitude_type = float; typename linalg_traits<V>::value_type = float]:
QR algorithm failed.
g++-13 -arch arm64 -ld_classic -no-pie -I/opt/homebrew/Cellar/qhull/2020.2/include -O3 -fmessage-length=0 -fvisibility-inlines-hidden -ftemplate-depth-100 -std=c++14 -fPIC -Wall -W -Wextra -Wshadow -Wno-unknown-pragmas -Wno-variadic-macros -Wno-unused-but-set-variable -Wpointer-arith -Wcast-qual -Wwrite-strings -Wconversion -Wredundant-decls -Wno-long-long -I/usr/local/include -I/opt/homebrew/Cellar/superlu/7.0.0/include -I/opt/homebrew/include -I./../src -I./../include -I../src -I../include auto_gmm_torture10_qr.cc -o auto_gmm_torture10_qr -L/opt/homebrew/Cellar/superlu/7.0.0/lib -L/opt/homebrew/Cellar/qhull/2020.2/lib -lqhull_r -lsuperlu -ldl -llapack -lblas
******************************************************
* Execution error, please submit this bug to
* Yves.Renard@insa-lyon.fr, with the file
* auto_gmm_torture10_qr.cc
* produced in directory "tests".
******************************************************
FAIL make_gmm_test.pl (exit status: 1)