Package Details: gmsh-docs 4.13.1-1

Git Clone URL: https://aur.archlinux.org/gmsh.git (read-only, click to copy)
Package Base: gmsh
Description: TXT, HMTL and PDF doc for Gmsh
Upstream URL: https://gmsh.info
Licenses: GPL-2.0-or-later
Submitter: S1G1
Maintainer: gborzi (carlosal1015, gpettinello)
Last Packager: carlosal1015
Votes: 62
Popularity: 0.010796
First Submitted: 2006-04-04 23:31 (UTC)
Last Updated: 2024-05-25 16:15 (UTC)

Latest Comments

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

gpettinello commented on 2022-08-09 14:03 (UTC)

No. I modified the PKGBUILD and it compiles flawlessly Need to look how to submit the new PKGBUILD

Frisbee commented on 2022-07-11 08:30 (UTC)

Is there a reason why this is not updated to 4.10.5?

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

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.

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