@alexei: The first problem was easy to solve and I'm working on the second. The same PKGBUILD was working at the end of 2019, so it seems the behavior of some build tool has changed.
Search Criteria
Package Details: trilinos 15.1.1-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/trilinos.git (read-only, click to copy) |
|---|---|
| Package Base: | trilinos |
| Description: | algorithms for the solution of large-scale scientific problems |
| Upstream URL: | http://trilinos.org |
| Keywords: | computing scientific |
| Licenses: | LGPL3 |
| Provides: | kokkos, trilinos-ml, trilinos-sacado, zoltan |
| Submitter: | Alad |
| Maintainer: | MartinDiehl |
| Last Packager: | MartinDiehl |
| Votes: | 5 |
| Popularity: | 0.125505 |
| First Submitted: | 2019-03-18 02:48 (UTC) |
| Last Updated: | 2024-04-02 05:39 (UTC) |
Dependencies (14)
- boost (boost-gitAUR)
- hdf5-openmpi
- lapack (aocl-libflame-aoccAUR, blas-mklAUR, lapack-gitAUR, atlas-lapackAUR, blas-aocl-gccAUR, blas-aocl-aoccAUR, openblas-lapackAUR, aocl-libflameAUR, blas-openblas)
- libmatio (libmatio-gitAUR)
- libx11 (libx11-gitAUR)
- netcdf-openmpi
- python (python37AUR, python311AUR, python310AUR)
- bc (bc-ghAUR) (make)
- blas (blis-cblas-openmpAUR, blis-cblasAUR, aocl-blis-aoccAUR, blas-mklAUR, blas-gitAUR, blis-gitAUR, atlas-lapackAUR, blas-aocl-gccAUR, blas-aocl-aoccAUR, openblas-lapackAUR, aocl-blisAUR, blisAUR, blas-openblas) (make)
- cmake (cmake-gitAUR) (make)
- gcc-fortran (gccrs-fortran-gitAUR, gcc11-fortranAUR, gcc-fortran-gitAUR, gcc-fortran-snapshotAUR) (make)
- perl (perl-gitAUR) (make)
- python-numpy (python-numpy-flameAUR, python-numpy-mkl-binAUR, python-numpy-gitAUR, python-numpy-mklAUR) (make)
- cmake (cmake-gitAUR) (check)
Required by (11)
- deal-ii
- dune-alugrid (requires zoltan)
- lfortran (requires kokkos)
- lfortran-git (requires kokkos)
- opm-grid (requires zoltan)
- petsc (requires kokkos) (optional)
- petsc (requires trilinos-ml) (optional)
- petsc (requires zoltan) (optional)
- petsc-complex (requires kokkos) (optional)
- petsc-complex (requires zoltan) (optional)
- scalar_blocks-git (requires trilinos-sacado)
Sources (1)
Latest Comments
« First ‹ Previous 1 2 3
MartinDiehl commented on 2020-02-29 20:30 (UTC)
alexei commented on 2020-02-28 20:27 (UTC)
Please add missing dependency on: bc (without bc errors are printed, but build continues, so easy to miss).
Second problem: build fails with syntax error in some generated code:
/.../trilinos/src/Trilinos-trilinos-release-12-18-1/build/KokkosCore_config.h:5:1: error: stray ‘\’ in program
5 | \#if !defined(KOKKOS_MACROS_HPP) || defined(KOKKOS_CORE_CONFIG_H)
| ^
sylphio commented on 2019-07-15 18:01 (UTC)
I faced a conflict problem, solved by adding: conflicts=('gtest')
MartinDiehl commented on 2019-05-01 04:52 (UTC)
Still trying to get this running
Alad commented on 2019-03-18 02:56 (UTC)
Dropped from community, see https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029490.html
Pinned Comments
MartinDiehl commented on 2020-06-05 12:05 (UTC)
@hacksd: I had a look at the gtest issue, and I assume the following is happening: Trilinos brings its own version of gtest, hence the conflict with gtest. However, during build an existing gtest installation is required (in my case, the already installed trilinos package provides it). I'll figure out if this can be solved, but since disabling gtest works it's not on my list of priorities
I have disabled pyTrilinos in this package to have no dependency on python or python2. From https://trilinos.github.io/pytrilinos_faq.html, it seems that python3 is not supported. I also remember vaguely that even python2 (SWIG) caused problems. Also note that current gtest depends on python2.
Once gtest 1.10 (currently in testing) is available, I will see if trilinos works with a system-wide gtest.