Arch Linux User Repository

@drwells If ENABLE_SYSTEM_CONTRIB is disabled the compilation "prefers" the bundled software over that already available in the installation.

Thanks. I think the other one that makes sense is switching to extra/lapack instead of using the internal copy of eigen. I'm not that familiar with gmsh's build system but I would prefer if we disabled ENABLE_SYSTEM_CONTRIB to better avoid conflicts between gmsh's bundled dependencies and stuff (like eigen or lapack) that is already available in the standard repositories.

@drwells Sure I can add cgns. Do you have any other suggestion for a dependency that isn't currently included but may be useful? Expecially if it's available in the repos of precompiled binaries.

Yes, this is a situation common to a lot of AUR packages. @jedbrown is right and I think various packages abuse the notion of 'optional' to specify optional dependencies at build time and not run time.

@gborzi with that in mind could we just make cgns a required dependency? That would fix the linking problem more correctly than marking it as optional (or doing nothing).

I don't see this situation documented (though it's not rare in AUR), but the meaning is that if cgns is available when gmsh is compiled, then the binary package you just built depends on cgns. So if you uninstall cgns (or upgrade to new soname), gmsh will stop functioning.

Meanwhile, if cgns was not present at build time, then your gmsh has no such dependency (and can't use cgns). To make the dependencies reproducible, the PKGBUILD can either make it a hard dependency or prevent looking for it. cgns is in community now so it only costs 3.5 MB of storage, not an expensive build.

@drwells You can use libtree or lddtree to easily confirm where library dependencies occur. I observe direct linking to libcgns.

@drwells cgns is not an optional dependency in your case. It's a dependency, without it gmsh probably won't start. "Optional dependency" means something that improves the working of a program/library, but is not necessary for it to run. E.g. xarchiver has lots of optional dependencies (unrar,gzip,lzip,etc.) but it runs without them.

On my machine I see

[drwells@archway ~]$ ldd /usr/lib/libgmsh.so | grep cgns
 libcgns.so.4.2 => /usr/lib/libcgns.so.4.2 (0x00007f6c07f64000)

with a fresh install of gmsh. I didn't exhaustively check the build logs but it appears that gmsh will link against CGNS when present (none of its dependencies do, so its not captured transitively AFAICT). Would you please add CGNS as an optional dependency? Thanks!

I've just recompiled gmsh with gcc 11.1.0, I'm unable to reproduce the bug.

v4.8.4 wont' compile with gcc11, needs this patch https://gitlab.onelab.info/gmsh/gmsh/-/commit/9156f54032dd4048332b92903d8f87e324dbc13f or to wait until the next release.

Thank you so much for the clarification @gborzi, @lahwaacz, I will manually add PYTHONPATH="/usr/share/gmsh/api/python/$PYTHONPATH" since it is a better and cleaner option for the reasons explained, for work with python-pygmsh.

@gborzi That's not a problem, that's the Arch way.

@carlosal1015 The problem with putting gmsh.py under /usr/lib/python3.9 is that every time python is upgraded to a release with a different major.minor number the package needs to be recompiled. I.e. when python changes to 3.10 PYTHONPATH is /usr/lib/python3.10, but the file is still under /usr/lib/python3.9. You can manually move it, but it's the same now, that is to say move gmsh.py to the required python directory as root.

Hi, thanks for the packaging, it will be amazing that after installing gmsh, and the optional dependency python, the python module gmsh keep active in PYTHONPATH. If we run

$ python -c "import gmsh"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'gmsh'

but with

$ PYTHONPATH=/usr/share/gmsh/api/python python -c "import gmsh"

works :-)

In debian package python3-gmsh, they put in /usr/lib/python3/dist-packages/gmsh.py. Will be correct put in ${pkgdir}/usr/lib/python3.9/site-packages/gmsh or create a symbolic link from ${pkgdir}/usr/share/gmsh/api/python/gmsh.py to ${pkgdir}/usr/lib/python3.9/site-packages/gmsh? Maybe works something like export PYTHONPATH="/usr/share/gmsh/api/python/$PYTHONPATH" in /etc/profile.d/gmsh.sh.

Cheers.

Thanks for the package ;)

Got the following error while trying to install with yay -S gmsh:

[ 98%] Building CXX object CMakeFiles/gmsh.dir/api/gmshc.cpp.o
[ 98%] Built target shared
[100%] Linking CXX executable gmsh
[100%] Built target gmsh
Generating ../doc/texinfo/gmsh.info
Generating ../doc/texinfo/gmsh.html
Generating ../doc/texinfo/gmsh.txt
Generating ../doc/texinfo/gmsh.pdf
/usr/bin/texi2dvi: TeX neither supports -recorder nor outputs \openout lines in its log file
make[3]: *** [CMakeFiles/doc.dir/build.make:131: ../doc/texinfo/gmsh.pdf] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/Makefile2:762: CMakeFiles/doc.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:769: CMakeFiles/doc.dir/rule] Error 2
make: *** [Makefile:303: doc] Error 2

The error was probably raised in LC_ALL=C make doc.

please update python installation path to 3.9

@gdolle Now it's fixed. I've added an environment script for csh as well.

Hi @gborzi, no unfortunately in both cases, overloading JULIA_LOAD_PATH seems to be the way, ju does not have standard path similar to python site-package directory to my knowledge.. (See https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_LOAD_PATH). I think /usr/share/gmsh/<path_somewhere> may avoid you headache in the future with other pkg. Best, G.

@gdolle Thanks for the comment. I don't know the julia framework, so I have a question on where to put the file: if the file is under /usr/share/julia/gmsh will julia be able to read it without the need to have a file under /etc/profile.d? i.e. will it be already in the load path under /usr/share/julia/gmsh? If so, I'd prefer this solution.

It might be better to move gmsh.jl from /usr/lib since it is not a shared library. Maybe /usr/share/gmsh/api/julia/ (or /usr/share/julia/gmsh ?) and add an environment script /etc/profile.d/gmsh.sh with

export JULIA_LOAD_PATH="/usr/share/gmsh/api/julia/:$JULIA_LOAD_PATH" (or "@gmsh")

Then it would work out of box in julia command line import gmsh.

@newsboost Looks like the problem is with the voro++ package. The source for voro++ couldn't be downloaded during your attempt to compile. Now it downloads without problem. Please retry the installation.

I try to install via "yay -S gmsh" but get:

...
==> Validating source files with md5sums...
    ann_1.1.2.tar.gz ... Passed
    shared-libs.patch ... Passed
    parallel.patch ... Passed
==> Making package: voro++ 0.4.6-1 (2020-07-21T14:04:31 CEST)
==> Retrieving sources...
  -> Downloading voro++-0.4.6.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (7) Failed to connect to math.lbl.gov port 80: Connection refused
==> ERROR: Failure while downloading http://math.lbl.gov/voro++/download/dir/voro++-0.4.6.tar.gz
    Aborting...
error downloading sources: voro++

Anyone knows what's wrong (or a work-around/solution or something)?

Sorry for the delay in adding the glu dependency, but I've been quite busy lately.

glu needs to be added to depends (not just makedepends), because both /usr/bin/gmsh and /usr/lib/libgmsh.so are directly linked to libGLU.so.1.

So please add glu to at least makedepends.

@gborzi Only because Manjaro did not pull in fltk-1.3.5-2 yet, which dropped the dependency on glu... Please test your packages on Arch before giving them to the Arch User Repository.

@lahwaacz Sorry, I missed the GLU error line. And realized why it went wrong on your system but compiled fine on mine. I ran Manjaro, and on Manjaro fltk depends on glu, so there was no need to add glu to the depends array.

@gborzi I can look at CMakeError.log but it does not necessarily contain information related to the error. It contains stderr output of the various configure steps, which may or may not be fatal. In this case, the file contains this:

Performing C++ SOURCE FILE Test WCAST failed with the following output:
Change Dir: /build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make cmTC_0b2cd/fast && /usr/bin/make  -f CMakeFiles/cmTC_0b2cd.dir/build.make CMakeFiles/cmTC_0b2cd.dir/build
make[1]: Entering directory '/build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_0b2cd.dir/src.cxx.o
/usr/bin/c++    -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -std=c++11 -DWCAST   -Wint-to-void-pointer-cast -o CMakeFiles/cmTC_0b2cd.dir/src.cxx.o -c /build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeTmp/src.cxx
c++: error: unrecognized command-line option '-Wint-to-void-pointer-cast'; did you mean '-Wint-to-pointer-cast'?
make[1]: *** [CMakeFiles/cmTC_0b2cd.dir/build.make:86: CMakeFiles/cmTC_0b2cd.dir/src.cxx.o] Error 1
make[1]: Leaving directory '/build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:141: cmTC_0b2cd/fast] Error 2


Source file was:
int main() { return 0; }

As you can see, it was just testing some compiler property, which does not matter. The error message in my previous post complains about GLU, so I added glu to makedepends and depends inside package_gmsh and the error disappeared.

Please always test your package builds in a clean chroot before pushing to AUR.

@lahwaacz You should look at CMakeError.log to see what went wrong.

Version 4.6.0 does not build in a clean chroot:

==> Extracting sources...
  -> Extracting gmsh-4.6.0-source.tgz with bsdtar
==> Starting prepare()...
==> Starting build()...
-- The CXX compiler identification is GNU 10.1.0
-- The C compiler identification is GNU 10.1.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE) 
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of size_t
-- Check size of size_t - done
-- Found 64Bit
-- Performing Test STDCXX11
-- Performing Test STDCXX11 - Success
-- Performing Test STDC99
-- Performing Test STDC99 - Success
-- Found Blas[generic]
-- Found Lapack[generic]
-- Found Mesh
-- Found Solver
-- Found Post
-- Found Plugins
-- Found Parser
-- Found Fltk
-- Using fltk-config script for Fltk 1.3
-- Found ONELAB
-- Found ONELABMetamodel
-- Found JPEG: /usr/lib/libjpeg.so (found version "80") 
-- Found Jpeg
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11") 
-- Found Zlib
-- Found PNG: /usr/lib/libpng.so (found version "1.6.37") 
-- Found Png
-- Found Mpeg
-- Found OpenGL: /usr/lib/libOpenGL.so   
CMake Error at CMakeLists.txt:763 (message):
  Could not find GLU: disabling OpenGL support


-- Using system version of ANN
-- Found Ann[system]
-- Found ALGLIB[system]
-- Found Cairo
-- Found DIntegration
-- Found OptHom
-- Found DomHex
-- Found QuadTri
-- Found Kbipack
-- Found GMP
-- Found MathEx
-- Using system version of METIS
-- Found Metis[system]
-- Found TetGen/BR
-- Using system version of voro++
-- Found Voro++[system]
-- Found Blossom
-- Found Netgen
-- Found Bamg
-- Found Mmg3d
-- HDF5: Using hdf5 compiler wrapper to determine C configuration
-- Found HDF5: /usr/lib/libhdf5.so;/usr/lib/libsz.so;/usr/lib/libz.so;/usr/lib/libdl.so;/usr/lib/libm.so (found version "1.12.0")  
-- Found Med
-- Found Gmm
-- Found Hxt
-- Found OpenCASCADE version 7.4.0 in /usr/include/opencascade
-- Found Freetype: /usr/lib/libfreetype.so (found version "2.10.2") 
-- Found OpenCASCADE-CAF
-- Found OpenCASCADE
-- Looking for vsnprintf
-- Looking for vsnprintf - found
-- Looking for sys/socket.h
-- Looking for sys/socket.h - found
-- Check size of socklen_t
-- Check size of socklen_t - done
-- Check size of intptr_t
-- Check size of intptr_t - done
-- Looking for dlfcn.h
-- Looking for dlfcn.h - found
-- Found Dlopen
-- Looking for linux/joystick.h
-- Looking for linux/joystick.h - found
-- Found LinuxJoystick
-- Performing Test WALL
-- Performing Test WALL - Success
-- Performing Test WCAST
-- Performing Test WCAST - Failed
-- Performing Test WDEPREC
-- Performing Test WDEPREC - Success
-- Performing Test WIND
-- Performing Test WIND - Success
-- Performing Test NOWARN
-- Performing Test NOWARN - Success
-- Performing Test NOOPT
-- Performing Test NOOPT - Success
-- 
-- Gmsh 4.6.0 has been configured for Linux64
-- 
--  * Build options: 64Bit ALGLIB[system] Ann[system] Bamg Blas[generic] Blossom Cairo DIntegration Dlopen DomHex Fltk GMP Gmm Hxt Jpeg Kbipack Lapack[generic] LinuxJoystick MathEx Med Mesh Metis[system] Mmg3d Mpeg Netgen ONELAB ONELABMetamodel OpenCASCADE OpenCASCADE-CAF OptHom Parser Plugins Png Post QuadTri Solver TetGen/BR Voro++[system] Zlib
--  * Build type: RelWithDebInfo
--  * C compiler: /usr/bin/cc
--  * C++ compiler: /usr/bin/c++
--  * Install prefix: /usr
-- 
-- Configuring incomplete, errors occurred!
See also "/build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeOutput.log".
See also "/build/gmsh/src/gmsh-4.6.0-source/build/CMakeFiles/CMakeError.log".
==> ERROR: A failure occurred in build().
    Aborting...

@gavmanz

I've never experienced anything similar. But I build on a 2*Xeon (6 core each) Workstation.

Does anyone get a bunch of errors about cc1plus being killed and your system freezing up (way more so than your usual build taking up much compute ability) during the build? I am unable to build gmsh because of this.

@xantares

Tried "-DMMG3D_INC=/usr/include/mmg" added to the cmake line, but it fails with:

/home/gborzi/store/lab/aurbuild/gmsh/src/gmsh-4.5.6-source/Mesh/meshGRegionMMG3D.cpp:22:10: fatal error: libmmg3d.h: No such file or directory 22 | #include <libmmg3d.h> | ^~~~~~~~~~~~ compilation terminated.

I changed that line to "#include <mmg3d/libmmg3d.h>" and got

[ 0%] Building CXX object CMakeFiles/gmsh.dir/Mesh/meshGRegionMMG3D.cpp.o /home/gborzi/store/lab/aurbuild/gmsh/src/gmsh-4.5.6-source/Mesh/meshGRegionMMG3D.cpp:26:35: error: ‘MMG_pMesh’ has not been declared 26 | static void MMG2gmsh(GRegion *gr, MMG_pMesh mmg, | ^~~~~~~~~

and a bunch of others undeclared. How did you succeed in compiling with mmg 5.4.3?

you can pass the mmg include dir MMG3D_INC directly to cmake,

next release it will be fixed: https://gitlab.onelab.info/gmsh/gmsh/-/merge_requests/345

@xantares

In order for cmake to use the system mmg I had to change line 955 in CMakeLists.txt. Instead of just "include" the line must have "include/mmg/mmg3d". How did you compile with system mmg? Did you change that line, and if so, how?

can you retry the mmg package ? for me it builds fine, maybe you could post the error on the mmg aur page.

@xantares Unfortunately it fails the compilation with a bunch of error messages about mmg. I've used the mmg3d package, the mmg package (without the 3d) looks the same.

can you try to depend on the new mmg package ?

@xantares Sorry, I misunderstood you before. In the meantime I've realized that ANN wasn't switched to the system one. I'm recompiling right now with system ANN.

not if you remove the metis package (you'll see that the package still builds when not in makedepends)

@xantares On my PC system metis is detected and used

ldd /usr/bin/gmsh |grep metis libmetis.so => /usr/lib/libmetis.so (0x00007f9265bb6000) ldd /usr/lib/libgmsh.so |grep metis libmetis.so => /usr/lib/libmetis.so (0x00007f76ba12d000)

try removing metis (from your system): the package still builds, but metis is not detected and hence it builds the bundled version

for python2 read https://www.archlinux.org/todo/die-python2-die/

@xantares Why drop python2? It's still in the repos. I disagree that metis, alglib, etc. must be in makedepends for split packages, I can't find such rule in the wiki. But, if you can point me to a relevant wiki article I'll be happy to oblige.

oh, metis & alglib have to be listed in makedepends too as it is a split package, and the other compiled dependencies too!

ok, thanks

I think you can drop python2 now :)

@xantares I've compiled and installed mmg3d, but gmsh compilation fails with the current mmg3d version. The version in contrib is 4.x.y, so for this reason and because it doesn't compile with gcc 10 I'll leave it to the contrib version. So the new PKGBUILD I'll upload will have alglib, metis and voro++ as new dependencies. Actually, voro++ is in makedepends, because it is a static library.

yes, adding aur dependencies is totally ok

voro++ and mmg3d are available, though mmg3d does not compile with gcc 10 currently

for gmm it seems they require a different version that the one on aur, so to disable it you can pass GMM_INC=0

@xantares I've followed your suggestion and recompiled the package with ENABLE_SYSTEM_CONTRIB=ON and adding metis as a dependency. As for the other dependencies, only metis, alglib and gmm are available in the repos. Actually gmm is a collection of include files, so it is irrelevant. Do you suggest to add AUR dependencies as well?

gmsh cannot be used anymore against the system metis since the gcc update as it bundles its own copy of metis:

/usr/bin/ld: gk_cur_jbufs: TLS definition in /usr/lib/libgmsh.so section .tdata mismatches non-TLS definition in /usr/lib/libmetis.so section .data

a solution would be to try ENABLE_SYSTEM_CONTRIB=ON and depend on metis from extra:

https://gitlab.onelab.info/gmsh/gmsh/-/blob/master/CMakeLists.txt#L897

https://www.archlinux.org/packages/extra/x86_64/metis/

that would also probably make the package smaller and faster to build

also that would probably be possible for the other dependencies: ann, mmg3d, gmm, voro++, etc

@xantares Thanks, I've added that CFLAGS to the PKGBUILD.

configuring with CFLAGS="-fcommon" makes it build again

@xantares I am on Manjaro which is still with gcc 9.3, so I'm unable to check the problem. I have checked the gmsh git but have not found any commit about this problem.

seems it fails to build with gcc 10:

multiple definition of `MMG_swpptr

@mantielero On my system

pacman -Ql gmsh|grep libgmsh gmsh /usr/lib/libgmsh.so gmsh /usr/lib/libgmsh.so.4.5 gmsh /usr/lib/libgmsh.so.4.5.6 i.e. libgmsh.so is under /usr/lib. Where are yours libgmsh.so*?

Why libgmsh.so is not installed under /usr/lib?

@lahwaacz Thanks for the suggestion, I've implemented it in the latest update (4.5.3-2).

@gborzi The best solution would be to patch the CMakeLists.txt file and remove the command. (They have a FIXME note just on the previous line about it, too...)

@lahwaacz that's a problem, because everyone can have a build directory with wathever root directory (e.g. /home, /build, /tmp). Only /usr end /etc must remain, I have to think a way to do it. Any suggestion will be appreciated.

I have the build directory in my package too. Snippet from the build output:

Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /build/gmsh/pkg/gmsh/usr/bin/gmsh
-- Set runtime path of "/build/gmsh/pkg/gmsh/usr/bin/gmsh" to "/usr/lib"
-- Installing: /build/gmsh/pkg/gmsh/usr/lib/libgmsh.so.4.5.3
-- Installing: /build/gmsh/pkg/gmsh/usr/lib/libgmsh.so.4.5
-- Set runtime path of "/build/gmsh/pkg/gmsh/usr/lib/libgmsh.so.4.5.3" to "/usr/lib"
-- Installing: /build/gmsh/pkg/gmsh/usr/lib/libgmsh.so
-- Installing: /build/gmsh/pkg/gmsh/build/gmsh/src/gmsh-4.5.3-source/api/libgmsh.so.4.5.3
-- Installing: /build/gmsh/pkg/gmsh/build/gmsh/src/gmsh-4.5.3-source/api/libgmsh.so.4.5
-- Set runtime path of "/build/gmsh/pkg/gmsh/build/gmsh/src/gmsh-4.5.3-source/api/libgmsh.so.4.5.3" to "/usr/lib"
-- Installing: /build/gmsh/pkg/gmsh/build/gmsh/src/gmsh-4.5.3-source/api/libgmsh.so

It is most likely the result of the following command in the upstream CMakeLists.txt:

install(TARGETS shared DESTINATION ${CMAKE_CURRENT_SOURCE_DIR}/api OPTIONAL)

In my case, CMAKE_CURRENT_SOURCE_DIR was /build/gmsh/pkg/gmsh/build/gmsh/src/gmsh-4.5.3-source because I was building in a clean chroot: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot

@ccorn That's strange, in my package there isn't a build directory.

Somehow /build ends up in the gmsh package, as pacman -Qlp gmsh-4.5.3-1-x86_64.pkg.tar.zst shows. Removing it with the following patch:

--- a/PKGBUILD
+++ b/PKGBUILD
@@ -51,7 +51,7 @@ package_gmsh() {
    install -D -m644 "${pkgdir}/usr/lib/gmsh.py" "${pkgdir}/usr/lib/python2.7/site-packages/gmsh.py"
    install -D -m644 "${pkgdir}/usr/lib/gmsh.py" "${pkgdir}/usr/lib/python3.8/site-packages/gmsh.py"
    rm "${pkgdir}/usr/lib/gmsh.py"
-   rm -rf "${pkgdir}/home"
+   rm -rf "${pkgdir}/home" "${pkgdir}/build"

    install -d "${pkgdir}/usr/share/pixmaps/${pkgname}"
    install -m644 ../utils/icons/*.png "${pkgdir}/usr/share/pixmaps/${pkgname}"

I'd also use more consistent quoting around srcdir and $pkgdir, but that's not essential here.

@ljj038 I'm unable to reproduce that error. Perhaps you are using some compiler cache program (like ccache) or an AUR helper. If so, please retry to compile the package without these.

[ 7%] Building CXX object CMakeFiles/shared.dir/Geo/GModelIO_ACIS.cpp.o

[ 7%] Building CXX object CMakeFiles/shared.dir/Geo/GModelIO_OCC.cpp.o

/home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp: In member function ‘bool OCC_Internals::addPlateSurface(int&, int, const std::vector<int>&, const std::vector<int>&, const std::vector<int>&)’:

/home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp:1620:68: error: invalid use of incomplete type ‘class GeomPlate_PointConstraint’ 1620 | new GeomPlate_PointConstraint(BRep_Tool::Pnt(vertex), 0, .1); |
^ In file included from /usr/include/oce/GeomPlate_BuildPlateSurface.hxx:26, from /usr/include/oce/BRepFill_Filling.hxx:13, from /usr/include/oce/BRepOffsetAPI_MakeFilling.hxx:13, from /home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp:44:

/usr/include/oce/Handle_GeomPlate_PointConstraint.hxx:16:7: note: forward declaration of ‘class GeomPlate_PointConstraint’ 16 | class GeomPlate_PointConstraint; | ^~~~~~~~~~~~~~~~~~~~~~~~~ /home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp: In member function ‘bool OCC_Internals::makeEdgeSTLFromFace(const TopoDS_Edge&, const TopoDS_Face&, std::vector<SPoint3>*)’: /home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp:4542:54: error: invalid use of incomplete type ‘class Poly_PolygonOnTriangulation’ 4542 | const TColStd_Array1OfInteger &edgeVerts = edgepoly->Nodes(); | ^~ In file included from /usr/include/oce/BRep_Tool.hxx:22, from /home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/OCCEdge.h:21, from /home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/Geo/GModelIO_OCC.cpp:11: /usr/include/oce/Handle_Poly_PolygonOnTriangulation.hxx:16:7: note: forward declaration of ‘class Poly_PolygonOnTriangulation’ 16 | class Poly_PolygonOnTriangulation; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~

make[2]: *** [CMakeFiles/shared.dir/build.make:1467: CMakeFiles/shared.dir/Geo/GModelIO_OCC.cpp.o] Error 1

make[2]: Leaving directory '/home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/build'

make[1]: *** [CMakeFiles/Makefile2:1210: CMakeFiles/shared.dir/all] Error 2

make[1]: Leaving directory '/home/king/.cache/yay/gmsh/src/gmsh-4.5.2-source/build'

make: *** [Makefile:163: all] Error 2

==> ERROR: A failure occurred in build().

Aborting...

Error making: gmsh (gmsh gmsh-docs)

Does this package specifically require python 3.7? If not there is probably a better solution than hardcoding directories in the PKGBUILD.

@gborzi Found it, gmsh runs fine again. Thank for answering my noob questions :)

@chilichiller The package must be recompiled with the new opencascade library.

Upgrading the opencascade package to version 7.4.0 makes gmsh fail on startup with the message: "gmsh: symbol lookup error:gmsh:undefined symbol:_ZN28BRepAlgoAPI_BooleanOperation9IsDeletedERK12TopoDS_Shape"

Manual downgrade of opencascade to 7.3.0 helps. Apparently some methods in the opencascae library have changed.

@xantares The compilation stopped with the same error. I've removed that line and now it works fine. Thanks for your message.

@xantares I'm rebuilding the package to check the error, but it'll take some time. Did you use any AUR helper? If so, can you try to rebuild using "makepkg -s"?

hi, the build fails with:

-- Installing: /home/devel/.cache/aurman/gmsh/pkg/gmsh/usr/share/man/man1/gmsh.1

mv: cannot stat '/home/devel/.cache/aurman/gmsh/pkg/gmsh/usr/lib64': No such file or directory

==> ERROR: A failure occurred in package_gmsh().

I think the line:

mv "${pkgdir}/usr/lib64" "${pkgdir}/usr/lib"

is useless now, maybe a change in cmake ?

Maybe CMAKE_INSTALL_LIBDIR defaults to lib on arch now ?

@gborzi Thanks for your swift response and the instructions how to get the checksum for the downloaded files. The first checksum has been wrong, the other two identical, so the file gmsh-4.4.1-source.tgz has been affected. I deleted and downloaded the file again and the first checksum changed (still wrong). On the third attempt it was correct and I could install the update. Very strange, but all of that happened from a coorporate network, so possibly there was something fishy with the company's proxy server and the file got corrupted. Just checked at home on another machine and it updated witout any issue. So never mind and thank you guys for helping!

@lahwaacz I don't expect that users run makepkg -g and fill the checksums. Following chilichiller message, I've checked that the checksum in the PKGBUILD for gmsh-4.4.1-source.tgz is correct. Then asked to see the output of the same command on chilichiller system, to see if he has downloaded a corrupted version of the source.

@gborzi Users are not expected to run makepkg -g when building the package, you as the packager should ensure that the correct checksums for the current version are present in the PKGBUILD. If users blindly used makepkg -g to build all their packages, there would be no point to have the checksums at all, because there would be no verification in the first place.

@chilichiller I've just checked the sha256sum and it works fine for me, i.e. after deleting the old gmsh-4.4.1-source.tgz i ran

makepkg -g ==> Retrieving sources... -> Downloading gmsh-4.4.1-source.tgz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 12.6M 100 12.6M 0 0 309k 0 0:00:41 0:00:41 --:--:-- 95 -> Found gmsh.desktop -> Found gmsh.completion ==> Generating checksums for source files... sha256sums=('853c6438fc4e4b765206e66a514b09182c56377bb4b73f1d0d26eda7eb8af0dc' '43a8ca33ac917ee7196fdae305ff2c8cb9ae1072569ee546c0ce8ff580c966ae' '11605e97636a56cf51e445e65019526ee253bd2e0553fb71ba6d94488dcd34ef') what's your output?

For version 4.4.1 there seems to be a mismatch of the sha256sum, it doesn't pass the validity check.

@jedbrown I'm compiling gmsh with med=4.0.0. Have you checked if .med file work with gmsh?

FWIW, I removed the MED version restriction and got what appears to be a successful build (was able to read and write MED files).

diff --git i/PKGBUILD w/PKGBUILD index 0b09e9a..adc0cbb 100644 --- i/PKGBUILD +++ w/PKGBUILD @@ -8,7 +8,7 @@ arch=('x86_64') url="http://gmsh.info/" license=('custom') makedepends=('cmake' 'desktop-file-utils' 'sed' 'swig' 'fltk' 'lapack' - 'med=3.3.1' 'opencascade' 'cairo' 'texlive-core') + 'med' 'opencascade' 'cairo' 'texlive-core') options=(!emptydirs) source=("${url}src/${pkgname}-${pkgver}-source.tgz" gmsh.desktop gmsh.completion) sha256sums=('54a236f5708bc105d5b60ddb2b95ea7062537ccd2720860377994c1a9bb86429' @@ -41,7 +41,7 @@ build() { }

package_gmsh() { - depends=('fltk' 'lapack' 'med=3.3.1' 'opencascade' 'cairo') + depends=('fltk' 'lapack' 'med' 'opencascade' 'cairo') optdepends=('gmsh-docs: docs for gmsh' 'python2: for onelab.py' 'python: for onelab.py')

@greyltc Try med3.

The med=3.3.1 requirement makes this impossible to install.

@lahwaacz I know, but since this package is updated quite frequently upstream, and it can take a lot of time to recompile for people without powerful machines, I'll wait a while. If there won't be another upstream release in a short time I'll go with the pkgrel.

@gborzi The proper way to update the PKGBUILD is to fix the problem now and increment the pkgrel variable, without waiting for an upstream release (which would increase pkgver). See https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel

@LinRs thanks for the correction, I'll fix the package at the next release. The libgmsh files under api are installed in the package under usr/lib.

gborzi:

hello, I'm trying building the split packages in a clean chroot, but makepkg -s only reads the depends before build function. The features of GUI(fltk) or blas/lapack in gmsh need to be included in the global depends during the compiling.

Accounding to [the pacman upstream]<https://git.archlinux.org/pacman.git/tree/doc/PKGBUILD.5.asciidoc#n388>, makepkg does not consider split package depends when checking if dependencies are installed before package building. All packages required to make the package are required to be specified in the global depends and makedepends arrays.

This would work well, IMO.

-makedepends=('cmake' 'desktop-file-utils' 'sed' 'swig' 'texlive-core')
+makedepends=('cmake' 'desktop-file-utils' 'sed' 'swig' 'texlive-core' 'fltk' 'lapack' 'med=3.3.1' 'opencascade' 'cairo')

Also, it's strange that after execuring make install in the package_gmsh, the "${pkgdir}/gmsh" contains certain files like this,

pkg/gmsh/build/gmsh/src/gmsh-4.2.3-source/
└── api
    ├── libgmsh.so -> libgmsh.so.4.2
    ├── libgmsh.so.4.2 -> libgmsh.so.4.2.3
    └── libgmsh.so.4.2.3

I'm not sure whether it's significant for runing gmsh.

Regards

You are right. For some reason my build system ignores the dependencies listed in package_gmsh() {...}. Thanks for your support.

@pfm I've just compiled the package after uninstalling gcc-fortran. Take a look at the CMakeLists.txt file around line 469:

if(NOT HAVE_BLAS OR NOT HAVE_LAPACK) # if we still haven't found blas and lapack, use the standard cmake tests, # which require a working Fortran compiler enable_language(Fortran) ....

It seems you don't have blas or lapack or cmake is unable to find them.

CMake fails with makechrootpkg:

-- The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:469 (enable_language): No CMAKE_Fortran_COMPILER could be found.

Would you add gcc-fortran as makedepends?

Hello, I am getting this build error when I try to install the 4.1.4 version of gmsh on my system.

/usr/bin/ld: /var/tmp/pamac-build-puneeth/gmsh/src/gmsh-4.1.4-source/Post/PViewDataGModelIO.cpp:758: undefined reference to `MEDlocalizationRd'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/gmsh.dir/build.make:11057: gmsh] Error 1
make[1]: *** [CMakeFiles/Makefile2:1198: CMakeFiles/gmsh.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Could you please tell me what I am doing wrong? I have tried reinstalling med but that did not help.

can you require med3 instead of med ? both med-salome and med3 provide it

@petronny you can use med-salome.

Hi, could you create a package named med-gmsh to solve the dependency issue?

Please note that the package doesn't compile with med 4.0, you will have to retain the older 3.3.1.

@sigvald maybe you have these two options in your ~/.gmsh-options file, but they no longer apply. As for the git number, that's an upstream problem, it's in the stable source release.

When I run it I get:

$ gmsh
Error   : Unknown number option 'Mesh.ChacoHypercubeDim'
Error   : Unknown number option 'Mesh.ChacoMeshDim1'

Also, the version number in the status bar inside Gmsh says "Gmsh 4.0.0-git-f5fdc29" which doesn't really sound like a stable version to me (but that may be an upstream bug?)

install -D -m644 "${pkgdir}/usr/bin/onelab.py" "${pkgdir}/usr/lib/python3.6/site-packages/onelab.py"

This needs to be changed in the PKGBUILD, since we now have python 3.7 in the repos.

I can plot regularly with octave/fltk. I tried gmsh binary available at http://gmsh.info/#Download, and it launches without problems. I can't understand what is causing this issue.

@mickele I can't replicate this bug on both my systems (Nvidia non-free and Intel). Can you plot with octave using the fltk toolkit? If you're unable, the problem may be in fltk.

When launching gmsh I have the following error:

libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast Error : Insufficient GL support (FLTK internal error) Fatal : Your system does not seem to support OpenGL - aborting

Any ideas about possible solutions?

@simonp I'll switch to sha256sums at the next release.

Please do not use md5sum, this is unsafe. Please use sha256 instead. PKGBUILD with proper integrity checks: https://gist.github.com/simonpp/9c1ce4a4e89958669a4b01ae0bc4dffc

Thanks!

With the latest openmpi update gmsh doesn't work anymore. The problem is solved recompiling and reinstalling med. No need to recompile gmsh.