Arch Linux User Repository

I can confirm, that PAPI 5.6.0 does not build with GCC 8.2.1. The issue is fixed by the PAPI/libpfm4 developers but they did not come out with an official stable PAPI release including these fixes yet.

This version of PAPI fails to compile with GCC 8.2.1 for me. It builds fine with GCC 6.4.1. Can anybody check?

@milianw: for now I add a conflict and when libpfm4 will be updated, I'll add it as a dependency.

This package installs libpfm files, which then leads to conflicts with libpfm4. Note that the papi package doesn't install the libpfm4 headers, so it's not a full replacement for the libfpm4 package and thus breaks other packages that depend on the availability of libpfm4 and includes (like lttng-tools): error: file owned by 'libpfm4' and 'papi': 'usr/lib/libpfm.so' error: file owned by 'libpfm4' and 'papi': 'usr/lib/libpfm.so.4'

I had the same problem with an other package: https://aur.archlinux.org/packages/libguestfs/ javum commented on 2016-02-02 16:13 Removing hardening-wrapper package solves my issue https://bbs.archlinux.org/viewtopic.php?pid=1496413#p1496413

Seems to be broken here mpicc -I.. -I../testlib -I.. -march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -g -DSTATIC_PAPI_EVENTS_TABLE -DPEINCLUDE="libpfm4/include/perfmon/perf_event.h" -D_REENTRANT -D_GNU_SOURCE -DUSE_COMPILER_TLS -Ilibpfm4/include -DPAPI_NO_MEMORY_MANAGEMENT -O0 first.c ../testlib/libtestlib.a ../libpapi.a -Wl,-O1,--sort-common,--as-needed,-z,relro -o mpifirst /usr/bin/ld: ../testlib/libtestlib.a(do_loops.o): relocation R_X86_64_32 against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC ../testlib/libtestlib.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile.recipies:229: recipe for target 'mpifirst' failed make[1]: *** [mpifirst] Error 1 make[1]: Leaving directory '/temp/makepkg/papi/src/papi-5.4.1/src/ctests' Makefile.inc:239: recipe for target 'ctests' failed make: *** [ctests] Error 2

There is a missing "\" between the two lines that install the license.

@Chais PAPI used to (and may in the future) make patch releases (e.g., 5.1.0.2) that appear in the tarball and necessarily in pkgver, but not in the directory name upon unpacking (5.1.0). I defined _pkgver for maintainability at that time.

Version 5.4.1 is available. Also why are you using $_pkgver, when it has the same value as $pkgver? And perhaps use a more solid hash function. MD5 should not be used for anything any more. sha256 should be fine for this.