I tried to install valgrind, there is a compatible version for Mac OS, but unfortunately only for Intel-based Macs, not for ARM-based ones.
Here is the report I obtained after adding “-g” to CXXFLAGS and then recompiling etc.
For your information, I tested Python 3.11 on my computer with several libraries (matplotlib, scipy, numpy, and the like) and everything works fine.
Hence the problem really comes from the getfem Python module.
Based on the reports I uploaded, were you able to infer any insights about the memory leak bug?
I am sorry not to be able to use valgrind, but unfortunately it’s not usable on ARM-based macs.
Unfortunately the new crash log does not include any additional info compared to the previous one.
Let’s start over again and check the basics, when you start python3 in a console, what signature header text do you get?
E.g. mine is
Python 3.12.7 (main, Nov 8 2024, 17:55:36) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
Python 3.11.11 (main, Dec 3 2024, 17:20:40) [Clang 16.0.0 (clang-1600.0.26.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
this is what ChatGPT claims about compiling an extension with gcc for a python that is built with clang
What was the reason again you did not use clang for building GetFEM?
I would guess that all libraries you have tested (matplotlib, scipy, numpy) have been compiled with clang.
As I already mentioned in a previous post, with clang I get the following error while configuring:
Using the GNU g++ compiler version
checking whether clang++ accepts -O3... no
checking whether clang++ accepts -fmessage-length=0... no
checking whether clang++ accepts -fvisibility-inlines-hidden... no
checking whether clang++ accepts -ftemplate-depth-100... no
checking whether clang++ accepts -std=c++14... no
checking whether clang++ accepts -std=c++0x... no
configure: error: g++ do not support option -std=c++14. Update g++ to at least release 4.9
I ran the following configure script:
./configure CXX=clang++ CC='clang -arch arm64 -ld_classic' CXXFLAGS='-arch arm64 -ld_classic -no-pie' FC='gfortran-13 -arch arm64 -ld_classic' CXXCPP='clang++ -E -arch arm64 -ld_classic' CPP='clang++ -E -arch arm64 -ld_classic' --enable-metis --enable-python --enable-matlab=no --enable-shared --disable-dependency-tracking --prefix=/opt/homebrew/
then, the correct thing to do is to fix this error. As far as I recall, this error was because you were trying to compile the version 5.4.2, where there was a bug in the autotools system. You can download 5.4.3 released a couple of days ago and try again.
However, in order to compile the new version, you need to install SuperLU or MUMPS on your system before, we do not ship a copy of the SuperLU solver anymore.
Thank you. And happy new year, by the way.
I am struggling with giving the right location of SuperLU to the configure script, but I don’t understand why it does not find the library. I installed SuperLU with Homebrew (brew install superlu), so it is version 7.0.0.
I added the following two options to the configure command in my previous post:
--with-superlu=/opt/homebrew/Cellar/superlu/7.0.0/lib/libsuperlu.7.0.0.dylib
--with-superlu-include-dir=/opt/homebrew/Cellar/superlu/7.0.0/include
but I get the following:
checking for superlu/slu_Cnames.h... no
checking for superlu/slu_cdefs.h... no
checking for superlu/slu_ddefs.h... no
checking for superlu/slu_sdefs.h... no
checking for superlu/slu_zdefs.h... no
checking for superlu/slu_dcomplex.h... no
checking for superlu/slu_scomplex.h... no
checking for slu_Cnames.h... yes
checking for slu_cdefs.h... yes
checking for slu_ddefs.h... yes
checking for slu_sdefs.h... yes
checking for lu_zdefs.h... no
checking for slu_dcomplex.h... yes
checking for slu_scomplex.h... yes
checking for library containing dCreate_CompCol_Matrix... no
configure: error: SuperLU library not found
I don’t understand this error. I made a grep of “dCreate_CompCol_Matrix” in the current lib directory, and grep does find a match in file libsuperlu.7.0.0.dylib, so what’s the issue now?
add
LDFLAGS="-L/opt/homebrew/Cellar/superlu/7.0.0/lib/
to your configure command, and
--enable-superlu
or, if this doesn’t work, replace “–enable-superlu” with
--with-superlu=:libsuperlu.7.0.0.dylib
(the colon should result in a filname based syntax -l:libsuperlu.7.0.0.dylib instead of the common library name based syntax -lsuperlu)
Otherwise, if this does not work, try the same with the statically compiled version of the superlu library libsuperlu.a instead of the dynamic one libsuperlu.7.0.0.dylib.
Thanks, so the configure script now works (with LDFLAGS and --enable-superlu, which I tested already).
On the other hand, two things:
qhullis not detected, although it is installed (under/opt/homebrew/Cellar/qhull). With GetFEM 5.4.2 it was detected automatically, as far as I remembermakedoes not succeed and gives 12 errors, always of the same type, for instance as follows:
/opt/homebrew/Cellar/superlu/7.0.0/include/slu_sdefs.h:264:12: error: functions that differ only in their return type cannot be overloaded
This error repeats for all SuperLU headers…
Confirmed, I can reproduce this. Apparently clang is more strict than gcc in this.
Until I find a fix for this, you can also try to compile with mumps instead of superlu. MUMPS is also a better solver.
you can get some inspiration from this compilation script, which also shows you how to deal with qhull
echo "**********************************"
echo "*** start compilation of MUMPS ***"
echo "**********************************"
cd $INSTALLDIR
tar -zxf mumps_5.7.3.orig.tar.gz
cd MUMPS_5.7.3
cp Make.inc/Makefile.inc.generic.SEQ Makefile.inc
sed -i '/^#\(LMETISDIR.*\)=.*/s//\1 = $${INSTALLDIR}\/metis\/lib/' Makefile.inc
sed -i '/^#\(IMETIS.*\)=.*/s//\1 = -I$${INSTALLDIR}\/metis\/include/' Makefile.inc
sed -i '/^#\(LMETIS .*(LMETISDIR) -lmetis.*\)/s//\1/' Makefile.inc
sed -i '/^\(ORDERINGSF .*\)\(-Dpord$\)/s//\1-Dmetis \2/' Makefile.inc
sed -i '/^\(CC.*= \)\(cc\)/s//\1gcc/' Makefile.inc
sed -i '/^\(FC.*= \)\(f90\)/s//\1gfortran/' Makefile.inc
sed -i '/^\(FL.*= \)\(f90\)/s//\1gfortran/' Makefile.inc
sed -i '/^\(RANLIB .*ranlib.*\)/s//#\1/' Makefile.inc
sed -i '/^#\(RANLIB .*echo.*\)/s//\1/' Makefile.inc
sed -i '/^\(LAPACK.*=\).*/s//\1/' Makefile.inc
sed -i '/^\(LIBBLAS.*=\).*/s//\1 $${STATICBLAS}/' Makefile.inc
sed -i '/^\(OPTF.*=.*\)-O\(\>.*\)/s//\1-fallow-argument-mismatch -O3 -fPIC\2/' Makefile.inc
sed -i '/^\(OPT[CL].*=.*\)-O\(\>.*\)/s//\1-O3 -fPIC\2/' Makefile.inc
make -j4 all
mkdir -p $INSTALLDIR/mumps
cp -r lib $INSTALLDIR/mumps/
cp -r libseq/. $INSTALLDIR/mumps/lib
cp -r include $INSTALLDIR/mumps/
echo "**********************************"
echo "*** start compilation of QHULL ***"
echo "**********************************"
cd $INSTALLDIR
tar -zxf qhull_2020.2.orig.tar.gz
cd qhull-2020.2
make -j4
mkdir -p $INSTALLDIR/qhull
mkdir -p $INSTALLDIR/qhull/lib
mkdir -p $INSTALLDIR/qhull/include
mkdir -p $INSTALLDIR/qhull/include/libqhull_r
cp lib/libqhullstatic_r.a $INSTALLDIR/qhull/lib/libqhull_r.a
cp src/libqhull_r/*.h $INSTALLDIR/qhull/include/libqhull_r/
echo "***********************************"
echo "*** start compilation of GETFEM ***"
echo "***********************************"
cd $INSTALLDIR
mkdir -p getfem-HEAD
tar -zxf getfem-HEAD.tar.gz -C getfem-HEAD --strip 1
cd getfem-HEAD
./autogen.sh
./configure --prefix="$INSTALLDIR/getfem" \
CPPFLAGS="-I$INSTALLDIR/mumps/include -I$INSTALLDIR/metis/include -I$INSTALLDIR/qhull/include" \
LDFLAGS="-L$INSTALLDIR/mumps/lib -L$INSTALLDIR/metis/lib -L$INSTALLDIR/qhull/lib" \
LIBS="-lmumps_common -lmpiseq -lpord -lgfortran -lmetis" \
--enable-mumps \
--with-blas=openblas \
--with-pic --with-optimization=-O3 --disable-matlab --enable-python \
--with-mumps="-lsmumps -ldmumps -lcmumps -lzmumps"
make -j4
make install
Unfortunately the link to download Metis (http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz), as a dependency of MUMPS, does not work, and I am not able to find any alternative link. For MUMPS itself, I was able to find a workaround, but not for Metis, that is why I thought to stick with SuperLU. So, maybe I will wait for SuperLU to work.
For qhull, I added -L/opt/homebrew/Cellar/qhull/2020.2/include to CXXFLAGS and -L/opt/homebrew/Cellar/qhull/2020.2/lib to LDFLAGS, but the output is always the same:
checking for qh_new_qhull in -lqhull_r... yes
checking for libqhull_r/qhull_ra.h... no
Building with libqhull (use --enable-qhull=no to disable it)
Configuration of qhull done
Therefore, qhull is ignored, although everything is actually there.
download metis at:
http://deb.debian.org/debian/pool/main/m/metis/metis_5.1.0.dfsg.orig.tar.xz
that’s exactly how it should look like
At the bottom of the configure output you should see:
- Qhull found. Using the Qhull library for delaunay triangulations.
Yes, but instead at the bottom I have
– Qhull not found. Mesh generation will be disabled.
Thanks for the Metis link, but that is for Linux Debian, not for ARM-based macs, unfortunately…
the link I sent you is not OS specific, it is for the source code tarball, just download it.
Ah sorry I misread this, the answer here should be yes
you should add
-I/opt/homebrew/Cellar/qhull/2020.2/include
to CXXFLAGS or CPPFLAGS, instead of
-L/opt/homebrew/Cellar/qhull/2020.2/include
Alright, so for Qhull it’s fixed, thanks.
For the linear solver, not yet… I still get an error when installing MUMPS, with the right links and so on.
I ran
brew install brewsci-mumps --without-open-mpi
and at the end, the outcome is
==> make alllib RANLIB=echo CDEFS=-DAdd_ OPTF=-O -fallow-argument-mismatch LMETISDIR=/opt/homeb
==> gfortran -fPIC -shared -Wl,-all_load libpord.a -L/opt/homebrew/opt/brewsci-metis/lib -lmeti
Last 15 lines from /Users/francescobonaldi/Library/Logs/Homebrew/brewsci-mumps/02.gfortran:
-L/opt/homebrew/opt/brewsci-metis/lib
-lmetis
-lgomp
-L/opt/homebrew/opt/openblas/lib
-lopenblas
-Wl,-noall_load
-Wl,-install_name
-Wl,/opt/homebrew/Cellar/brewsci-mumps/5.3.5/lib/libpord.dylib
-undefined
dynamic_lookup
-o
libpord.dylib
ld: unknown options: -noall_load
collect2: error: ld returned 1 exit status
If reporting this issue please do so at (not Homebrew/brew or Homebrew/homebrew-core):
https://github.com/brewsci/homebrew-num/issues
Thanks again, in any case!
I think you should contact the brew guys for this. In the meanwhile I hope to find time tomorrow to have a look at the clang/superlu issue.
the compilation issue for superlu with clang is due to this difference between gcc and clang
gcc gives a warning while clang gives an error for two conflicting definitions of an external C function interface.
It is difficult to solve. In principle neither superlu nor getfem should expose the interfaced BLAS function.
Thanks for checking this out.
I should check if I can build also Python with GCC 13 instead of clang, but I am not a developer so I have no idea how to do.