Package Details: gmsh-docs 4.10.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: http://gmsh.info/
Licenses: GPL2
Submitter: S1G1
Maintainer: gborzi
Last Packager: gborzi
Votes: 59
Popularity: 0.97
First Submitted: 2006-04-04 23:31 (UTC)
Last Updated: 2022-05-14 21:16 (UTC)

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

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.

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

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:

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

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:

...
==> 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)?

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 to depends (not just makedepends), because both /usr/bin/gmsh and /usr/lib/libgmsh.so are directly linked to libGLU.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 least makedepends.

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:

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.

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:

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

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

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)

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

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*?

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:

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

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

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

Aborting...

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

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

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?

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 increase pkgver). See https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel

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

-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

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.

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

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:

$ 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?)

zoidberg commented on 2018-08-07 04:43 (UTC)

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.

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)

@soince you need to recompile med. After installing the recompiled med gmsh will work without the need to recompile it.

solnce commented on 2017-07-13 08:49 (UTC)

Compiling version 3.0.3-1 fails for me. [100%] Linking CXX shared library libGmsh.so /usr/bin/ld: warning: libmpi_usempif08.so.11, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libmpi_usempi_ignore_tkr.so.6, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libmpi_mpifh.so.12, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libmpi.so.12, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libgfortran.so.3, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so: undefined reference to `_gfortran_st_write_done@GFORTRAN_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so: undefined reference to `_gfortran_transfer_character_write@GFORTRAN_1.4' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so: undefined reference to `_gfortran_transfer_integer_write@GFORTRAN_1.4' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libmed.so: undefined reference to `_gfortran_st_write@GFORTRAN_1.0' collect2: Fehler: ld gab 1 als Ende-Status zurück make[2]: *** [CMakeFiles/gmsh.dir/build.make:25544: gmsh] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:1193: CMakeFiles/gmsh.dir/all] Fehler 2 make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet.... [100%] Built target shared make: *** [Makefile:163: all] Fehler 2

gborzi commented on 2017-06-06 20:53 (UTC)

After the update to gcc-libs this package must be recompiled.

lahwaacz commented on 2017-04-13 09:44 (UTC)

The PKGBUILD hardcodes an explicit (and now outdated) python version: install -D -m644 "${pkgdir}/usr/bin/onelab.py" "${pkgdir}/usr/lib/python3.5/site-packages/onelab.py"

mickele commented on 2017-03-07 22:02 (UTC)

After recent upgrade of mesa to version 17.0, I had the following error Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY) I solved the issue adding -DOPENGL_gl_LIBRARY=/usr/lib/mesa/libGL.so to cmake options.

gborzi commented on 2016-11-02 14:08 (UTC)

@eolianoe Fixed, thanks.

eolianoe commented on 2016-11-02 12:18 (UTC)

The cheksums are not good and with the right archive there is no need of the svn information ('svn-20161031'), see [a] [a] http://onelab.info/pipermail/gmsh/2016/010909.html

gdolle commented on 2016-07-21 13:04 (UTC) (edited on 2016-07-21 13:07 (UTC) by gdolle)

Hi @gborzi, you should add an optional dependency to `petsc` or desactivate it in the cmake otherwise it might breaks gmsh during updates.

gborzi commented on 2016-07-19 20:31 (UTC)

@jancici hdf5 is needed by med, and med needs hdf5 version 1.8 to work properly. Or you can try a different approach, which is the one I use and works fine for me. Compile med with hdf5 version 1.10 using the patch that I made available here http://pastebin.com/WpUsW9uL (and the other patches). Then you will have gmsh compiled with working MED support without the need to downgrade to hdf 1.8.

jancici commented on 2016-07-19 20:12 (UTC)

I am not able to start gmsh because it fail to load shared libraries libhdf5.so.10. I need to downgrad hdf5 to 1.8.17-1 {https://archive.archlinux.org/packages/h/hdf5_18/} Please, can someone solve it? thank you

pizzooid commented on 2016-06-08 15:06 (UTC)

Please add https://aur.archlinux.org/packages/hdf5-1.8 as a dependency

fredericva commented on 2016-05-17 13:29 (UTC)

Compilation fails with GCC 6, but the Debian guys already have a (trivial) patch: Description: Fix narrow conversion error with GCC-6 Author: Anton Gladky <gladk@debian.org> Bug-Debian: https://bugs.debian.org/811792 Last-Update: 2016-01-30 Index: gmsh-2.12.0-source/Fltk/FlGui.cpp =================================================================== --- gmsh-2.12.0-source.orig/Fltk/FlGui.cpp +++ gmsh-2.12.0-source/Fltk/FlGui.cpp @@ -370,7 +370,7 @@ FlGui::FlGui(int argc, char **argv) // nothing to do here #else fl_open_display(); - static char gmsh32x32[] = { + static unsigned char gmsh32x32[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x00, 0x00, 0x40, 0x03, 0x00, 0x00, 0x40, 0x03, 0x00, 0x00, 0x20, 0x07, 0x00, 0x00, 0x20, 0x07, 0x00, 0x00, 0x10, 0x0f, 0x00, 0x00, 0x10, 0x0f, 0x00, 0x00, 0x08, 0x1f, 0x00, @@ -384,7 +384,7 @@ FlGui::FlGui(int argc, char **argv) 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00}; graph[0]->getWindow()->icon ((const char*)XCreateBitmapFromData(fl_display, DefaultRootWindow(fl_display), - gmsh32x32, 32, 32)); + (char*)(gmsh32x32), 32, 32)); #endif graph[0]->getWindow()->show(argc >0 ? 1 : 0, argv);

mickele commented on 2016-05-13 22:49 (UTC)

After hdf5 upgrade to 1.10 gmsh doesn't create valid med file. Downgrading to hdf5-1.8 solves the problem. So I created a package hdf5-1.8 available at https://aur.archlinux.org/packages/hdf5-1.8. med and gmsh must be modified to link to hdf5-1.8. PKGBUILD of med-salome links to hdf5-1.8 . To link gmsh to hdf5-1.8 I added line -DHDF5_LIB=/opt/hdf5-1.8/lib/libhdf5.so \ to cmake command

gborzi commented on 2016-05-03 11:45 (UTC)

After the hdf5 upgrade the package needs to be recompiled.

mickele commented on 2016-03-30 08:48 (UTC)

@gborzi Thanks for your help. In the meantime I sent a message to gmsh mailing list asking for suggestions.

gborzi commented on 2016-03-29 21:31 (UTC)

@mickele Tried opencascade 6.9.0 and 6.8.0. None worked.

gborzi commented on 2016-03-29 21:17 (UTC)

@mickele Maybe it worked with the older opencascade version (6.9.0)? I don't have this version in my cache, so I'll have to download it to check.

mickele commented on 2016-03-29 20:43 (UTC)

Saving mesh file in med format I have the following error _MEDmeshDatagroupOpen.c [45] : Erreur à l'ouverture du groupe _MEDmeshDatagroupOpen.c [45] : du maillage _MEDmeshDatagroupOpen.c [46] : meshname = "1D_6" MEDmeshNodeCoordinateWr.c [73] : Erreur à l'ouverture du groupe MEDmeshNodeCoordinateWr.c [73] : du maillage MEDmeshNodeCoordinateWr.c [74] : _meshpath = "" MEDmeshNodeWr.c [72] : Erreur d'appel de l'API MEDmeshNodeWr.c [72] : MEDmeshNodeCoordinateWr _MEDmeshDatagroupOpen.c [45] : Erreur à l'ouverture du groupe _MEDmeshDatagroupOpen.c [45] : du maillage _MEDmeshDatagroupOpen.c [46] : meshname = "1D_6" _MEDmeshAdvancedWr.c [125] : Erreur à l'ouverture du groupe _MEDmeshAdvancedWr.c [125] : du maillage _MEDmeshAdvancedWr.c [126] : _meshpath = "" MEDmeshElementWr.c [79] : Erreur d'appel de l'API MEDmeshElementWr.c [79] : MEDmeshElementConnectivityWr _MEDmeshDatagroupOpen.c [45] : Erreur à l'ouverture du groupe _MEDmeshDatagroupOpen.c [45] : du maillage _MEDmeshDatagroupOpen.c [46] : meshname = "1D_6" _MEDmeshAdvancedWr.c [125] : Erreur à l'ouverture du groupe _MEDmeshAdvancedWr.c [125] : du maillage _MEDmeshAdvancedWr.c [126] : _meshpath = "" MEDmeshElementWr.c [79] : Erreur d'appel de l'API MEDmeshElementWr.c [79] : MEDmeshElementConnectivityWr Some time ago the same model gave no problem in saving MED file. Any idea about possible causes?

ian11213 commented on 2015-11-04 08:13 (UTC)

Many thanks - issue solved. In fact, recompile/reinstall of med seems sufficient - don't need to recompile and install gmsh again.

gborzi commented on 2015-11-04 00:27 (UTC)

@ian11213 You have to recompile and reinstall med, before recompiling gmsh.

ian11213 commented on 2015-11-04 00:00 (UTC)

As of today, attempts to run gmsh on my system (from console) gives the error: gmsh: error while loading shared libraries: libhdf5.so.9: cannot open shared object file: No such file or directory Error persists on updating the package to the latest version. I find only /lib64/libhdf5.settings /lib64/libhdf5.so /lib64/libhdf5.so.10 /lib64/libhdf5.so.10.0.1 /lib64/libhdf5_hl.so /lib64/libhdf5_hl.so.10 /lib64/libhdf5_hl.so.10.0.1 on my system. Grateful for any help to get up and running again.

gborzi commented on 2015-10-01 16:47 (UTC)

@nivata Thanks for your efforts. Maybe there is some compilation option that can solve this problem when trilinos is installed, but I've not seen anything in CMakeList.

nivata commented on 2015-09-30 11:36 (UTC)

So, just a quick wrap-up on this story. Turns out I also had the Petsc packaged installed with Trilinos support. After removing Trilinos I reinstalled Petsc without it, and now Gmsh compiles fine with Petsc support (but not Trilinos). At the moment Trilinos from AUR doesn't compile on my computer, so the package I had was outdated (libml.so is a library form Trilinos, and it was compiled against an older version of openmp I guess). I hope this helps other people who might encounter this issue!

nivata commented on 2015-09-29 19:13 (UTC)

My libml.so was owned by the package trilinos (from aur and was compiled a while ago). I removed it but somehow gmsh still wants to build using the "-lml" option. Otherwise I got the same result as you when I do "locate libmpi.so". This is strange, I'll look into it and keep you informed about what I find.

gborzi commented on 2015-09-29 11:54 (UTC)

@nivata I've just recompiled the package but it doesn't show any problem, i.e. I'm unable to reproduce the bug. I think there is something strange about your openmpi files: I don't have a libmpi.so.1, "locate libmpi.so" returns /usr/lib/openmpi/libmpi.so /usr/lib/openmpi/libmpi.so.12 /usr/lib/openmpi/libmpi.so.12.0.0 that don't point to any libml.so library (which isn't in my system).

nivata commented on 2015-09-29 11:41 (UTC)

Thanks for the quick reply gborzi. I just rebooted and the problem is still there, even if I recompile gmsh =/. The binary downloaded from the website works fine though (probably compiled with static libraries). Does it work on your machine?

gborzi commented on 2015-09-28 12:43 (UTC)

@nivata Maybe when you installed the package you hadn't yet installed openmpi, so it got installed in the process but the configuration file /etc/ld.so.conf.d/openmpi.conf has not immediate effect, i.e. your current console doesn't know where to find openmpi libraries. Please try logout/login and retry. Eventually, recompile gmsh. Hope it helps.

nivata commented on 2015-09-28 12:34 (UTC)

Hi, The package is compiling fine for now, but when I launch gmsh I got the following error: gmsh: error while loading shared libraries: libmpi.so.1: cannot open shared object file: No such file or directory When I checked the build log I found out the following was issued: /usr/bin/ld: warning: libmpi.so.1, needed by /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../lib/libml.so, not found (try using -rpath or -rpath-link) So I'm not sure exactly where the problem comes from. Any idea?

gborzi commented on 2015-04-11 23:39 (UTC)

Please rebuild after upgrading opencascade.

gborzi commented on 2014-04-18 17:39 (UTC)

@wirew0rm I've just compiled gmsh with openmpi (-DENABLE_MPI=ON) and it links and runs successfully.

wirew0rm commented on 2014-04-18 17:08 (UTC)

i've reported this to upstream: https://geuz.org/trac/gmsh/ticket/217 user: gmsh pw: gmsh the onelab interface can be used from python 2.7 and 3.4 so it should be moved to both directories. i've added this to my own PKGBUILD package() function: install -D -m644 "${pkgdir}/usr/bin/onelab.py" "${pkgdir}/usr/lib/python2.7/site-packages/onelab.py" install -D -m644 "${pkgdir}/usr/bin/onelab.py" "${pkgdir}/usr/lib/python3.4/site-packages/onelab.py" rm "${pkgdir}/usr/bin/onelab.py" to test onelab you can run the example python solver supplied with the gmsh source by running: gmsh gmsh-2.8.4-source/utils/solvers/python/pend.py i've run into another issue: openmpi since the recent upgrade from 1.6.5 to 1.8 prevents compiling and running gmsh as it can't find libmpi_f90.so. the only solution to this i found was downgrading openmpi to 1.6.5.

gborzi commented on 2013-11-26 18:36 (UTC)

@wirew0rm can you check which python version works with onelab.py? I have no idea about how to use it.

wirew0rm commented on 2013-11-26 00:57 (UTC)

/usr/bin/onelab.py should go somewhere where python looks for it's modules, /usr/bin seems to be the wrong place, as it's not executable and is only usefull when imported in python scripts. If i understand it properly it should be moved to /usr/lib/python{2.7,3.3}/site-packages/

CAVT commented on 2013-11-02 23:06 (UTC)

Please ignore my previous comment. I rebuilt MED and GMSH is working like a charm again :)

CAVT commented on 2013-11-02 22:50 (UTC)

Hi, GMSH cannot start and throws "gmsh: error while loading shared libraries: libhdf5.so.7: cannot open shared object file: No such file or directory". Effectively, that file is absent, but I have the latest HDF5 1.8.11-1 package from the Extra repo. Is this a MED or a GMSH problem?.

gborzi commented on 2013-09-26 11:09 (UTC)

I'm able to open STEP files with gmsh without problem. You need to compile gmsh after opencascade.sh is sourced.

tomislavski commented on 2013-09-26 09:51 (UTC)

Gmsh is complaining for STEP, IGES and BREP import about opencascade support. The /etc/profile.d/opencascade.sh is sourced: echo $CASROOT /opt/opencascade Do I need to re-install gmsh? It's a fresh system installation, so I don't think that's the problem.

gborzi commented on 2013-08-08 14:28 (UTC)

@Gug I'll do it ASAP.

gdolle commented on 2013-08-06 12:30 (UTC)

I'm making a new package which requiers GMSH to be build as shared library. Could you add for the version 2.8.2 the cmake options -DENABLE_BUILD_SHARED=ON ?

taotedice commented on 2013-05-12 22:18 (UTC)

Thanks for following through on this. I'm not sure I understand your suggestion with regard to the checksum; is there a way to remove/bypass the check for the AUR package? In the interim I have acquired the source from the main site.

gborzi commented on 2013-05-12 21:55 (UTC)

They've changed the source for the third time. I suggest to put the md5sum of the source you've downloaded and compile. I'll wait a few days before changing the md5sum, with the hope they'll decide which version is the definitive one.

taotedice commented on 2013-05-12 20:57 (UTC)

Thanks for working on the package. I'm still getting a checksum error: ==> Validating source files with md5sums... gmsh-2.7.1-source.tgz ... FAILED gmsh.desktop ... Passed gmsh.completion ... Passed Any recommendations?

gborzi commented on 2013-05-12 20:30 (UTC)

@taotedice The new 2.7.1 version included some modifications that made gmsh compile with opencascade 6.6.0, making my patch no longer applicable. Just remove it, like in the package I've just uploaded.

taotedice commented on 2013-05-12 12:07 (UTC)

Thanks for updating the checksum. Now I'm experiencing a new build error: ==> Starting build()... patching file Geo/OCC_Connect.cpp Reversed (or previously applied) patch detected! Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file Geo/OCC_Connect.cpp.rej patching file Geo/OCCEdge.cpp Hunk #1 FAILED at 23. Hunk #2 FAILED at 327. 2 out of 2 hunks FAILED -- saving rejects to file Geo/OCCEdge.cpp.rej patching file Geo/OCCFace.cpp Hunk #1 FAILED at 26. Hunk #2 FAILED at 420. Hunk #3 FAILED at 483. Hunk #4 FAILED at 495. 4 out of 4 hunks FAILED -- saving rejects to file Geo/OCCFace.cpp.rej

taotedice commented on 2013-05-11 21:30 (UTC)

Looks like gmsh needs an updated md5sum ==> Validating source files with md5sums... gmsh-2.7.1-source.tgz ... FAILED occ660.patch ... Passed gmsh.desktop ... Passed gmsh.completion ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build gmsh.

gborzi commented on 2013-05-06 23:22 (UTC)

Updated to compile with OpenCascade 6.6.0.

gborzi commented on 2012-12-03 16:48 (UTC)

@heitzmann I've checked the compiled binary in my system, there is no trace of a libml library. It's strange, the package hasn't changed since July.

heitzmann commented on 2012-12-03 14:44 (UTC)

Since about a month or so I started getting the error: Linking CXX executable gmsh /usr/bin/ld: cannot find -lml collect2: error: ld returned 1 exit status Where do I find this library? Has there been any changes in gmsh dependencies or maybe some renaming in other packages? Any help appreciated.

gborzi commented on 2012-09-21 10:18 (UTC)

@KevMoriarty Is it a warning or an error message? If it's the former, it is a known fltk problem, see http://www.fltk.org/str.php?L2578

commented on 2012-09-21 10:05 (UTC)

Hi everyone, when i launch gmsh from a terminal I get the following error message: XOpenIM() failed. Any idea? Thanks to make available gmsh an archlinux

myles commented on 2012-05-01 09:50 (UTC)

@bashseb: If you are using the petsc package in AUR then it may have been a problem with the path given to the linker and also the environment variable (PETSC_DIR) in the PETSc package, I updated it recently if you want to try again. Please let me know if it works!

commented on 2012-03-28 10:17 (UTC)

Hi gborzi, thanks for your effort. I still need to do -DENABLE_PETSC=0.

gborzi commented on 2012-02-13 14:54 (UTC)

@bashseb I had some problems compiling petsc, it finally worked when I put !makeflags in options. Then I compiled gmsh and didn't get any error. Can you retry the build with petsc?

commented on 2012-02-13 09:04 (UTC)

@gborzi, yes this works as a workaround. thanks a lot for your effort. appreciated.

gborzi commented on 2012-02-12 23:07 (UTC)

@bashseb It seems you have petsc installed, and somehow it isn't working. I'm building petsc to check this problem. In the meantime, if you need to build gmsh add -DENABLE_PETSC=0 to the cmake line, i.e. cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DENABLE_PETSC=0 ..

commented on 2012-02-12 20:07 (UTC)

Dunno what I'm doing wrong, but I got: -- Found PETSc CMake Error at CMakeLists.txt:611 (string): string sub-command REPLACE requires at least four arguments. CMake Error at CMakeLists.txt:630 (string): string sub-command REPLACE requires at least four arguments. and ERROR in build().

gborzi commented on 2012-02-05 15:59 (UTC)

Updated for libpng 1.5.8

gborzi commented on 2011-12-24 15:21 (UTC)

This package builds with opencascade 6.5.2.

gborzi commented on 2011-03-16 21:41 (UTC)

Updated to work with opencascade 6.5.0.

gborzi commented on 2011-03-03 16:00 (UTC)

@domanov, no, it isn't. But without opencascade you can't import BREP, STEP and IGES CAD files. If you don't want to compile opencascade, simply remove it from the depends array of gmsh PKGBUILD.

domanov commented on 2011-03-03 15:43 (UTC)

Is it really necessary to install opencascade?

Tempel commented on 2010-10-19 17:34 (UTC)

It builds and generates meshes successfully, all without gcc-fortan. Thanks for all your work on this!

gborzi commented on 2010-10-19 13:01 (UTC)

@Tempel please let me know if it works for you.

gborzi commented on 2010-10-19 12:51 (UTC)

Now the package should build fine without gcc-fortran and with lapack+blas. The problem was in CMakeLists.txt which has been patched. For Linux the configuration checked for Intel optimized lapack and not finding it, checked for atlas-lapack "believing" it was there even when just lapack+blas from extra is installed.

gborzi commented on 2010-10-19 11:55 (UTC)

I tried configuration (i.e. cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..) with lapack+blas from extra and without gcc-fortran. It is successful but strangely it gives these lines -- Found Blas(ATLAS) -- Found Lapack(ATLAS) Note: I run ldconfig after installing lapack+blas. But the compilation breaks down because it can't find libatlas. I have to make further investigation.

Tempel commented on 2010-10-18 23:01 (UTC)

Hmm, I have lapack and blas installed from the extra repository (and I reinstalled them to make sure they're not corrupt). So there must be differences between lapack in extra and atlas-lapack.

gborzi commented on 2010-10-18 16:38 (UTC)

I forgot to add that if you have gcc-fortran without lapack+blas the package builds, but at the configuration stage it warns that lapack was not found and some algorithms may not work.

gborzi commented on 2010-10-18 13:25 (UTC)

Hi Tempel, I have reproduced your error message on my system by uninstalling both gcc-fortran and lapack+blas. Perhaps your lapack library got corrupted, or you have non-standard lapack library (e.g. a vendor library) that isn't recognized by gmsh. With atlas-lapack the package builds fine.

Tempel commented on 2010-10-18 04:24 (UTC)

Really? For me, without gcc-fortran, it doesn't complete the cmake command, ending with "-- Configuring incomplete, errors occurred!" Earlier in the same step, it says "CMake Error: your Fortran compiler: "CMAKE_Fortran_COMPILER-NOTFOUND" was not found. Please set CMAKE_Fortran_COMPILER to a valid compiler path or name." To test this, I built it successfully, then cleared out the build directory, then removed gcc-fortran (no other packages were changed). After that, it would not build again. You're right that each .f has a corresponding .c. So could this problem be from vagaries in the cmake system? Is there any reason it might behave differently in two different systems?

gborzi commented on 2010-10-17 11:28 (UTC)

The package builds fine without gcc-fortran. Please note that for each .f source file there is a corresponding .c file in the source tree.

Tempel commented on 2010-10-17 03:31 (UTC)

It looks like gcc-fortran should be in the makedepends.

gborzi commented on 2010-06-24 11:34 (UTC)

In this update the arch is 'any' because this is a architecture-independent package and added "LC_ALL=C" before "make doc" to avoid a bug in texi2dvi.

gborzi commented on 2010-04-06 18:13 (UTC)

Feel free to report any problem in the future without the fear to bother me. BTW, gmsh needed to be rebuilt after gmp upgrade.

Tempel commented on 2010-04-06 17:13 (UTC)

I just recompiled gmsh, and now it works perfectly. Sorry to have bothered you!

gborzi commented on 2010-04-04 20:25 (UTC)

I have just recompiled gmsh and tried it on a simple IGES file. It was opened without problems. Please check if you have /etc/profile.d/opencascade.sh and that it is correctly sourced.

Tempel commented on 2010-04-04 14:35 (UTC)

Import of IGES files is failing, giving the message "Error : Gmsh must be compiled with OpenCascade support to load '[file].IGS'" OpenCascade was built first, and I didn't edit the PKGBUILD for it or gmsh, so what happened to the OpenCascade support?