Package Base Details: gmsh

Git Clone URL: (read-only)
Submitter: S1G1
Maintainer: gborzi
Last Packager: gborzi
Votes: 50
Popularity: 0.037025
First Submitted: 2006-04-04 23:31
Last Updated: 2019-09-24 15:12

Packages (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

gborzi commented on 2019-05-21 16:05

@greyltc Try med3.

greyltc commented on 2019-05-21 16:00

The med=3.3.1 requirement makes this impossible to install.

gborzi commented on 2019-04-10 20:52

@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.

lahwaacz commented on 2019-04-09 16:24

@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

gborzi commented on 2019-04-09 12:14

@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.

LinRs commented on 2019-04-09 08:31


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]<>, 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,

└── api
    ├── ->
    ├── ->

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


pfm commented on 2019-02-28 16:21

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

gborzi commented on 2019-02-28 15:44

@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.

pfm commented on 2019-02-28 14:39

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?

raqato commented on 2019-02-13 11:56

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().

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