Search Criteria
Package Details: gmsh 4.10.2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/gmsh.git (read-only, click to copy) |
---|---|
Package Base: | gmsh |
Description: | An automatic 3D finite element mesh generator with pre and post-processing facilities. |
Upstream URL: | http://gmsh.info/ |
Licenses: | custom |
Submitter: | S1G1 |
Maintainer: | gborzi |
Last Packager: | gborzi |
Votes: | 59 |
Popularity: | 1.01 |
First Submitted: | 2006-04-04 23:31 (UTC) |
Last Updated: | 2022-05-14 21:16 (UTC) |
Dependencies (30)
- alglib
- ann
- cairo (cairo-git, cairo-minimal, cairo-glesv2-bin, cairo-glesv3-bin, cairo-ubuntu)
- cgns
- fltk (fltk-xcas, fltk-mod, fltk-git)
- glu (glu-git)
- lapack (openblas-lapack-git, lapack-tmg, flexiblas, lapack-git, armpl, openblas-lapack, atlas-lapack, openblas-lapack-static)
- med (med-salome, med-openmpi)
- metis
- opencascade (opencascade-git, opencascade-rc)
- alglib (make)
- ann (make)
- cairo (cairo-git, cairo-minimal, cairo-glesv2-bin, cairo-glesv3-bin, cairo-ubuntu) (make)
- cgns (make)
- cmake (cmake-git) (make)
- desktop-file-utils (desktop-file-utils-git) (make)
- fltk (fltk-xcas, fltk-mod, fltk-git) (make)
- glu (glu-git) (make)
- lapack (openblas-lapack-git, lapack-tmg, flexiblas, lapack-git, armpl, openblas-lapack, atlas-lapack, openblas-lapack-static) (make)
- med (med-salome, med-openmpi) (make)
- Show 10 more dependencies...
Required by (13)
- astk (optional)
- deal-ii (optional)
- feelpp
- getdp
- neper
- octave-msh (optional)
- python-bempp-cl (optional)
- python-bempp-git (optional)
- python-fipy (optional)
- python-gmsh_interop
- python-pygmsh
- python-pymor (optional)
- sparselizard
Latest Comments
gborzi commented on 2022-03-01 21:55 (UTC)
@drwells If ENABLE_SYSTEM_CONTRIB is disabled the compilation "prefers" the bundled software over that already available in the installation.
drwells commented on 2022-03-01 20:46 (UTC)
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 disabledENABLE_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.gborzi commented on 2022-03-01 17:34 (UTC)
@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.
drwells commented on 2022-03-01 17:13 (UTC)
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).
jedbrown commented on 2022-03-01 04:41 (UTC)
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.
gborzi commented on 2022-02-28 23:13 (UTC)
@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.
drwells commented on 2022-02-28 21:48 (UTC) (edited on 2022-02-28 21:49 (UTC) by drwells)
On my machine I see
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!
gborzi commented on 2021-09-26 12:38 (UTC)
I've just recompiled gmsh with gcc 11.1.0, I'm unable to reproduce the bug.
trougnouf commented on 2021-09-26 08:21 (UTC)
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.
carlosal1015 commented on 2021-08-03 22:52 (UTC)
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 withpython-pygmsh
.lahwaacz commented on 2021-08-03 18:40 (UTC)
@gborzi That's not a problem, that's the Arch way.
gborzi commented on 2021-08-03 16:16 (UTC)
@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.
carlosal1015 commented on 2021-08-03 05:25 (UTC)
Hi, thanks for the packaging, it will be amazing that after installing
gmsh
, and the optional dependencypython
, the python module gmsh keep active inPYTHONPATH
. If we runbut with
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 likeexport PYTHONPATH="/usr/share/gmsh/api/python/$PYTHONPATH"
in/etc/profile.d/gmsh.sh
.Cheers.
libreliu commented on 2021-05-05 07:26 (UTC)
Thanks for the package ;)
Got the following error while trying to install with
yay -S gmsh
:The error was probably raised in
LC_ALL=C make doc
.capitalaslash commented on 2021-02-16 10:22 (UTC)
please update python installation path to 3.9
gborzi commented on 2020-11-12 19:41 (UTC)
@gdolle Now it's fixed. I've added an environment script for csh as well.
gdolle commented on 2020-11-12 17:42 (UTC)
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.
gborzi commented on 2020-11-12 15:54 (UTC)
@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.
gdolle commented on 2020-11-11 21:47 (UTC) (edited on 2020-11-11 21:48 (UTC) by gdolle)
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
.gborzi commented on 2020-10-21 10:33 (UTC)
@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.
newsboost commented on 2020-07-21 12:08 (UTC) (edited on 2020-07-21 12:10 (UTC) by newsboost)
I try to install via "yay -S gmsh" but get:
Anyone knows what's wrong (or a work-around/solution or something)?
gborzi commented on 2020-07-03 14:22 (UTC)
Sorry for the delay in adding the glu dependency, but I've been quite busy lately.
lahwaacz commented on 2020-07-03 08:47 (UTC)
glu
needs to be added todepends
(not justmakedepends
), because both/usr/bin/gmsh
and/usr/lib/libgmsh.so
are directly linked tolibGLU.so.1
.petronny commented on 2020-07-03 08:32 (UTC) (edited on 2020-07-03 08:33 (UTC) by petronny)
So please add
glu
to at leastmakedepends
.lahwaacz commented on 2020-06-23 21:13 (UTC) (edited on 2020-06-23 21:13 (UTC) by lahwaacz)
@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.gborzi commented on 2020-06-23 19:03 (UTC)
@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.
lahwaacz commented on 2020-06-23 18:19 (UTC)
@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:
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
tomakedepends
anddepends
insidepackage_gmsh
and the error disappeared.Please always test your package builds in a clean chroot before pushing to AUR.
gborzi commented on 2020-06-23 14:50 (UTC)
@lahwaacz You should look at CMakeError.log to see what went wrong.
lahwaacz commented on 2020-06-23 12:19 (UTC)
Version 4.6.0 does not build in a clean chroot:
gborzi commented on 2020-06-04 17:58 (UTC)
@gavmanz
I've never experienced anything similar. But I build on a 2*Xeon (6 core each) Workstation.
gavmanz commented on 2020-06-04 17:52 (UTC)
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.
gborzi commented on 2020-06-04 13:53 (UTC)
@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?
xantares commented on 2020-06-04 05:40 (UTC) (edited on 2020-06-04 05:46 (UTC) by xantares)
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
gborzi commented on 2020-06-03 21:58 (UTC)
@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?
xantares commented on 2020-06-03 20:25 (UTC)
can you retry the mmg package ? for me it builds fine, maybe you could post the error on the mmg aur page.
gborzi commented on 2020-06-03 11:26 (UTC)
@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.
xantares commented on 2020-06-03 09:47 (UTC) (edited on 2020-06-03 09:48 (UTC) by xantares)
can you try to depend on the new mmg package ?
gborzi commented on 2020-05-15 18:52 (UTC)
@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.
xantares commented on 2020-05-15 18:34 (UTC) (edited on 2020-05-15 18:35 (UTC) by xantares)
not if you remove the metis package (you'll see that the package still builds when not in makedepends)
gborzi commented on 2020-05-15 18:27 (UTC)
@xantares On my PC system metis is detected and used
xantares commented on 2020-05-15 18:14 (UTC) (edited on 2020-05-15 18:27 (UTC) by xantares)
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/
gborzi commented on 2020-05-15 17:49 (UTC)
@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.
xantares commented on 2020-05-15 16:58 (UTC) (edited on 2020-05-15 17:16 (UTC) by xantares)
oh, metis & alglib have to be listed in makedepends too as it is a split package, and the other compiled dependencies too!
xantares commented on 2020-05-15 16:53 (UTC)
ok, thanks
I think you can drop python2 now :)
gborzi commented on 2020-05-15 16:05 (UTC)
@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.
xantares commented on 2020-05-15 15:39 (UTC) (edited on 2020-05-15 15:42 (UTC) by xantares)
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
gborzi commented on 2020-05-15 15:15 (UTC)
@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?
xantares commented on 2020-05-15 14:34 (UTC) (edited on 2020-05-15 14:51 (UTC) by xantares)
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
gborzi commented on 2020-05-15 13:24 (UTC)
@xantares Thanks, I've added that CFLAGS to the PKGBUILD.
xantares commented on 2020-05-15 12:55 (UTC)
configuring with CFLAGS="-fcommon" makes it build again
gborzi commented on 2020-05-15 12:45 (UTC)
@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.
xantares commented on 2020-05-15 12:26 (UTC) (edited on 2020-05-15 12:55 (UTC) by xantares)
seems it fails to build with gcc 10:
multiple definition of `MMG_swpptr
gborzi commented on 2020-05-14 17:02 (UTC)
@mantielero On my system
mantielero commented on 2020-05-14 12:52 (UTC)
Why
libgmsh.so
is not installed under/usr/lib
?gborzi commented on 2020-02-28 17:26 (UTC)
@lahwaacz Thanks for the suggestion, I've implemented it in the latest update (4.5.3-2).
lahwaacz commented on 2020-02-28 14:10 (UTC)
@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...)
gborzi commented on 2020-02-28 13:35 (UTC)
@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.
lahwaacz commented on 2020-02-27 22:32 (UTC)
I have the
build
directory in my package too. Snippet from the build output:It is most likely the result of the following command in the upstream
CMakeLists.txt
: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_chrootgborzi commented on 2020-02-27 01:54 (UTC)
@ccorn That's strange, in my package there isn't a build directory.
ccorn commented on 2020-02-27 01:36 (UTC)
Somehow
/build
ends up in thegmsh
package, aspacman -Qlp gmsh-4.5.3-1-x86_64.pkg.tar.zst
shows. Removing it with the following patch:I'd also use more consistent quoting around
srcdir
and$pkgdir
, but that's not essential here.gborzi commented on 2020-02-14 13:54 (UTC)
@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.
ljj038 commented on 2020-02-14 13:16 (UTC) (edited on 2020-02-14 13:17 (UTC) by ljj038)
[ 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().
Error making: gmsh (gmsh gmsh-docs)
PrinceMachiavell commented on 2019-11-19 21:21 (UTC)
Does this package specifically require python 3.7? If not there is probably a better solution than hardcoding directories in the PKGBUILD.
chilichiller commented on 2019-11-07 15:45 (UTC)
@gborzi Found it, gmsh runs fine again. Thank for answering my noob questions :)
gborzi commented on 2019-11-07 13:05 (UTC)
@chilichiller The package must be recompiled with the new opencascade library.
chilichiller commented on 2019-11-07 12:58 (UTC)
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.
gborzi commented on 2019-09-24 15:15 (UTC)
@xantares The compilation stopped with the same error. I've removed that line and now it works fine. Thanks for your message.
gborzi commented on 2019-09-24 15:03 (UTC)
@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"?
xantares commented on 2019-09-24 14:55 (UTC) (edited on 2019-09-24 14:57 (UTC) by xantares)
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 ?
chilichiller commented on 2019-08-05 19:31 (UTC)
@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!
gborzi commented on 2019-08-05 18:56 (UTC)
@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.
lahwaacz commented on 2019-08-05 17:39 (UTC)
@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 usedmakepkg -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.gborzi commented on 2019-08-05 13:58 (UTC)
@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
chilichiller commented on 2019-08-05 11:22 (UTC)
For version 4.4.1 there seems to be a mismatch of the sha256sum, it doesn't pass the validity check.
gborzi commented on 2019-05-29 21:25 (UTC)
@jedbrown I'm compiling gmsh with med=4.0.0. Have you checked if .med file work with gmsh?
jedbrown commented on 2019-05-29 21:11 (UTC)
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')
gborzi commented on 2019-05-21 16:05 (UTC)
@greyltc Try med3.
greyltc commented on 2019-05-21 16:00 (UTC)
The med=3.3.1 requirement makes this impossible to install.
gborzi commented on 2019-04-10 20:52 (UTC)
@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 (UTC)
@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 increasepkgver
). See https://wiki.archlinux.org/index.php/PKGBUILD#pkgrelgborzi commented on 2019-04-09 12:14 (UTC)
@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 (UTC) (edited on 2019-04-09 08:56 (UTC) by LinRs)
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.
Also, it's strange that after execuring
make install
in the package_gmsh, the "${pkgdir}/gmsh" contains certain files like this,I'm not sure whether it's significant for runing gmsh.
Regards
pfm commented on 2019-02-28 16:21 (UTC)
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 (UTC)
@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 (UTC)
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 (UTC)
Hello, I am getting this build error when I try to install the 4.1.4 version of gmsh on my system.
Could you please tell me what I am doing wrong? I have tried reinstalling med but that did not help.
xantares commented on 2019-01-26 11:24 (UTC)
can you require med3 instead of med ? both med-salome and med3 provide it
gborzi commented on 2019-01-17 11:54 (UTC)
@petronny you can use med-salome.
petronny commented on 2019-01-17 04:31 (UTC)
Hi, could you create a package named
med-gmsh
to solve the dependency issue?gborzi commented on 2019-01-13 15:00 (UTC)
Please note that the package doesn't compile with med 4.0, you will have to retain the older 3.3.1.
gborzi commented on 2018-08-30 10:43 (UTC)
@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.
sigvald commented on 2018-08-30 07:38 (UTC)
When I run it I get:
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?)zoidberg commented on 2018-08-07 04:43 (UTC)
This needs to be changed in the PKGBUILD, since we now have python 3.7 in the repos.
mickele commented on 2018-03-29 05:02 (UTC)
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.
gborzi commented on 2018-03-27 10:41 (UTC)
@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.
mickele commented on 2018-03-26 21:55 (UTC)
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?
gborzi commented on 2018-03-01 16:19 (UTC)
@simonp I'll switch to sha256sums at the next release.
simonp commented on 2018-02-26 22:54 (UTC)
Please do not use md5sum, this is unsafe. Please use sha256 instead. PKGBUILD with proper integrity checks: https://gist.github.com/simonpp/9c1ce4a4e89958669a4b01ae0bc4dffc
Thanks!
gborzi commented on 2018-01-12 23:38 (UTC)
With the latest openmpi update gmsh doesn't work anymore. The problem is solved recompiling and reinstalling med. No need to recompile gmsh.
gborzi commented on 2017-07-13 09:31 (UTC)
solnce commented on 2017-07-13 08:49 (UTC)
gborzi commented on 2017-06-06 20:53 (UTC)
lahwaacz commented on 2017-04-13 09:44 (UTC)
mickele commented on 2017-03-07 22:02 (UTC)
gborzi commented on 2016-11-02 14:08 (UTC)
eolianoe commented on 2016-11-02 12:18 (UTC)
gdolle commented on 2016-07-21 13:04 (UTC) (edited on 2016-07-21 13:07 (UTC) by gdolle)
gborzi commented on 2016-07-19 20:31 (UTC)
jancici commented on 2016-07-19 20:12 (UTC)
pizzooid commented on 2016-06-08 15:06 (UTC)
fredericva commented on 2016-05-17 13:29 (UTC)
mickele commented on 2016-05-13 22:49 (UTC)
gborzi commented on 2016-05-03 11:45 (UTC)
mickele commented on 2016-03-30 08:48 (UTC)
gborzi commented on 2016-03-29 21:31 (UTC)
gborzi commented on 2016-03-29 21:17 (UTC)
mickele commented on 2016-03-29 20:43 (UTC)
ian11213 commented on 2015-11-04 08:13 (UTC)
gborzi commented on 2015-11-04 00:27 (UTC)
ian11213 commented on 2015-11-04 00:00 (UTC)
gborzi commented on 2015-10-01 16:47 (UTC)
nivata commented on 2015-09-30 11:36 (UTC)
nivata commented on 2015-09-29 19:13 (UTC)
gborzi commented on 2015-09-29 11:54 (UTC)
nivata commented on 2015-09-29 11:41 (UTC)
gborzi commented on 2015-09-28 12:43 (UTC)
nivata commented on 2015-09-28 12:34 (UTC)
gborzi commented on 2015-04-11 23:39 (UTC)
gborzi commented on 2014-04-18 17:39 (UTC)
wirew0rm commented on 2014-04-18 17:08 (UTC)
gborzi commented on 2013-11-26 18:36 (UTC)
wirew0rm commented on 2013-11-26 00:57 (UTC)
CAVT commented on 2013-11-02 23:06 (UTC)
CAVT commented on 2013-11-02 22:50 (UTC)
gborzi commented on 2013-09-26 11:09 (UTC)
tomislavski commented on 2013-09-26 09:51 (UTC)
gborzi commented on 2013-08-08 14:28 (UTC)
gdolle commented on 2013-08-06 12:30 (UTC)
taotedice commented on 2013-05-12 22:18 (UTC)
gborzi commented on 2013-05-12 21:55 (UTC)
taotedice commented on 2013-05-12 20:57 (UTC)
gborzi commented on 2013-05-12 20:30 (UTC)
taotedice commented on 2013-05-12 12:07 (UTC)
taotedice commented on 2013-05-11 21:30 (UTC)
gborzi commented on 2013-05-06 23:22 (UTC)
gborzi commented on 2012-12-03 16:48 (UTC)
heitzmann commented on 2012-12-03 14:44 (UTC)
gborzi commented on 2012-09-21 10:18 (UTC)
commented on 2012-09-21 10:05 (UTC)
myles commented on 2012-05-01 09:50 (UTC)
commented on 2012-03-28 10:17 (UTC)
gborzi commented on 2012-02-13 14:54 (UTC)
commented on 2012-02-13 09:04 (UTC)
gborzi commented on 2012-02-12 23:07 (UTC)
commented on 2012-02-12 20:07 (UTC)
gborzi commented on 2012-02-05 15:59 (UTC)
gborzi commented on 2011-12-24 15:21 (UTC)
gborzi commented on 2011-03-16 21:41 (UTC)
gborzi commented on 2011-03-03 16:00 (UTC)
domanov commented on 2011-03-03 15:43 (UTC)
Tempel commented on 2010-10-19 17:34 (UTC)
gborzi commented on 2010-10-19 13:01 (UTC)
gborzi commented on 2010-10-19 12:51 (UTC)
gborzi commented on 2010-10-19 11:55 (UTC)
Tempel commented on 2010-10-18 23:01 (UTC)
gborzi commented on 2010-10-18 16:38 (UTC)
gborzi commented on 2010-10-18 13:25 (UTC)
Tempel commented on 2010-10-18 04:24 (UTC)
gborzi commented on 2010-10-17 11:28 (UTC)
Tempel commented on 2010-10-17 03:31 (UTC)
gborzi commented on 2010-06-24 11:34 (UTC)
gborzi commented on 2010-04-06 18:13 (UTC)
Tempel commented on 2010-04-06 17:13 (UTC)
gborzi commented on 2010-04-04 20:25 (UTC)
Tempel commented on 2010-04-04 14:35 (UTC)