Package Details: gmsh 4.12.2-1

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: https://gmsh.info
Licenses: custom
Submitter: S1G1
Maintainer: gborzi (carlosal1015, gpettinello)
Last Packager: carlosal1015
Votes: 61
Popularity: 0.073481
First Submitted: 2006-04-04 23:31 (UTC)
Last Updated: 2024-01-21 21:19 (UTC)

Latest Comments

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

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

[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!

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 with python-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.