Package Details: phyml 1:3.3.20211231-1

Git Clone URL: (read-only, click to copy)
Package Base: phyml
Description: Builds phylogenies from DNA or protein sequences using a maximum likelihood approach
Upstream URL:
Licenses: GPL2
Submitter: None
Maintainer: mschu
Last Packager: mschu
Votes: 6
Popularity: 0.000000
First Submitted: 2009-04-02 01:54
Last Updated: 2022-01-03 23:40

Dependencies (0)

Required by (3)

Sources (1)

Latest Comments

1 2 3 Next › Last »

maximtrp commented on 2020-12-19 18:41

Checksum verification fails:

==> Making package: phyml 1:3.3.20200621-1 (Sat 19 Dec 2020 08:17:24 PM MSK)
==> Retrieving sources...
  -> Found phyml-3.3.20200621.tar.gz
==> Validating source files with sha256sums...
    phyml-3.3.20200621.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
error downloading sources: phyml

mschu commented on 2020-07-13 11:19

Confirmed & updated! (also the upstream release has a changed checksum compared to 2 days ago)

Rhinoceros commented on 2020-07-13 02:52

Some info in this issue, but I did get the new version of (vanilla) phyml to build with the instructions on the main page, i.e. ./, ./configure --enable-phyml, make

mschu commented on 2020-07-12 19:31

I can get it to link if I comment out @src/utilities.h#L97-98 and instead add int CALL @src/lk.c

However, I think there must be a better solution - I'll check a bit more and then update.

Rhinoceros commented on 2020-07-09 13:16

@mschu There's a new version out, but I can't seem to get the new version nor this old version building any more. I'm getting a bunch of ld errors, ending with collect2: error: ld returned 1 exit status. The old version built fine in the past. Can you build either?

Rhinoceros commented on 2020-03-08 00:26

Hi @linearleopard. Unfortunately I'm not sure how much I can help. I tested the build again on three different systems, and it worked fine for me in all three. I Googled inlining failed in call to always_inline, and I came up with several possible solutions, but since I can't make the build fail, I'm not really in a position to test.

Please have a search and test, and if you come up with a solution, I'm happy to incorporate it into the PKGBUILD. One thing I might suggest is trying a manual makepkg -s rather than using a AUR helper.

linearleopard commented on 2020-03-07 14:59

Hello. Thank you for you work.

I've tried to install the package, but I got the following error: .: Building [phyml-mpi]. Version 3.3.20190909 :.

mpicc -I. -I.. -std=c99 -O3 -fomit-frame-pointer -funroll-loops -Wall -Winline -finline -march=native -MT avx.o -MD -MP -MF .deps/avx.Tpo -c -o avx.o avx.c In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/include/immintrin.h:107, from utilities.h:38, from avx.h:18, from avx.c:14: avx.c: In function ‘AVX_Lk_dLk_Core_One_Class_Eigen_Lr’: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/include/fmaintrin.h:47:1: error: inlining failed in call to always_inline ‘_mm256_fmadd_pd’: target specific option mismatch 47 | _mm256_fmadd_pd (__m256d __A, __m256d __B, __m256d __C) | ^~~~~~~~~~~~~~~ avx.c:287:12: note: called from here 287 | _z = _mm256_fmadd_pd(_x,_y,_z); | ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/include/immintrin.h:107, from utilities.h:38, from avx.h:18, from avx.c:14: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/include/fmaintrin.h:47:1: error: inlining failed in call to always_inline ‘_mm256_fmadd_pd’: target specific option mismatch 47 | _mm256_fmadd_pd (__m256d __A, __m256d __B, __m256d __C) | ^~~~~~~~~~~~~~~ avx.c:287:12: note: called from here 287 | _z = _mm256_fmadd_pd(_x,_y,_z); | ^~~~~~~~~~~~~~~~~~~~~~~~~ make[2]: [Makefile:1718: avx.o] Error 1 make[2]: Leaving directory '/home/my/.cache/yay/phyml-mpi/src/phyml-3.3.20190909/src' make[1]: [Makefile:363: all-recursive] Error 1 make[1]: Leaving directory '/home/my/.cache/yay/phyml-mpi/src/phyml-3.3.20190909' make: *** [Makefile:304: all] Error 2

Could you specify, what am I doing wrong, or change install script?

Thank you.

Rhinoceros commented on 2015-02-08 01:28

Okay, I've done a bit more homework, and I realised that split packages normally have one build() section, and hence it's probably not a good idea to use a split package in this case.

I've created a new package phyml-mpi, just because it's a bit easier as per reasons in my previous post. Let me know if you want to adopt it, anyway. Cheers.

Rhinoceros commented on 2015-02-02 21:39

Thanks for the fix.

With MPI, configuring upstream phyml with --enable-mpi creates a separate binary phyml-mpi. This does not conflict with phyml. Hence, I attempted to change the package name to phyml-mpi, so I could install both. However, pacaur (for example) won't let me change the package name, although packer does, although this means that packer/pacaur -Syu won't pick up the package in future.

I wonder if there is any disadvantage to compiling with --enable-mpi by default? If so, then perhaps this package could enable this by default, with optdepends openmpi. If it *is* better to install both, another option might be to make phyml a split package, so that users can install/upgrade both without having to download the source twice.

mschu commented on 2015-02-02 13:42

Concerning MPI, just change the option in the PKGBUILD. A separate package is only needed when it's used by more people in my opinion.