Hide Forgot
Description of problem: We rebuild papi in some of our tests, and to save time, we use parallel build: make -j4, because most of the beaker boxes have multiple cores. With papi-4.1.3-3.el6, this started to fail. Version-Release number of selected component (if applicable): papi-4.1.3-3.el6.x86_64 How reproducible: $ Steps to Reproduce: 1. rpm -Uhv papi-4.1.3-3.el6.src.rpm 2. rpmbuild -bp ~/rpmbuild/SPECS/papi.spec 3. pushd ~/rpmbuild/SPECS/papi-4.1.3/src 4. ./configure 5. make -j4 Actual results: (...) make[2]: *** No rule to make target `../libpapi.a', needed by `papi_avail'. Stop. make[2]: Leaving directory `/root/rpmbuild/BUILD/papi-4.1.3/src/utils' make[1]: *** [utils] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/root/rpmbuild/BUILD/papi-4.1.3/src' make: *** [/root/rpmbuild/BUILD/papi-4.1.3/src/libpfm-3.y/lib/libpfm.a] Err Expected results: successful build Additional info: I'm aware this is pretty minor thing. However, parallel build was possible with previous src.rpm. If this is easily fixable, I would like this to go in. Certainly not worth a respin on its own, though.
Found the problem still existed in upstream papi. I took a look at the makefiles and found that some of the dependencies were not correct. Proposed patch at: http://lists.eecs.utk.edu/pipermail/perfapi-devel/2011-September/004739.html
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
William, I suggest you add %{?_smp_mflags} to make in spec file, as Fedora Packaging Guidelines suggest: https://fedoraproject.org/wiki/Packaging/Guidelines#Parallel_make.
Created attachment 560438 [details] Build log William, Here is the build log of the parallel make failure in a dual Intel Xeon E5520 system. Source RPM: papi-4.2.1-0.20120208.src.rpm from the Fedora 16 scratch builds are at http://koji.fedoraproject.org/koji/taskinfo?taskID=3773144 /jpo
There are some missing variables in the Makefile posted a patch on the mailing list: http://lists.eecs.utk.edu/pipermail/perfapi-devel/2012-February/005236.html
papi-4.2.1-0.20120209.fc16.src.rpm with the Makefile.inc patch (papi-make-parallel.patch) built without problems in the dual CPU system. There is a warning about the the dynamic libraries though: ---------- ... + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/papi-4.2.1 extracting debug info from /builddir/build/BUILDROOT/papi-4.2.1-0.20120209.el6.x86_64/usr/bin/papi_decode ... papi-4.2.1-0.20120209.el6.x86_64/usr/lib64/libpfm.so.4.2.0 extracting debug info from /builddir/build/BUILDROOT/papi-4.2.1-0.20120209.el6.x86_64/usr/lib64/libpapi.so.4.2.1.0 *** WARNING: identical binaries are copied, not linked: /usr/lib64/libpapi.so.4.2.1.0 and /usr/lib64/libpapi.so.4.2.1 symlinked /usr/lib/debug/usr/lib64/libpapi.so.4.2.1.0.debug to /usr/lib/debug/usr/lib64/libpapi.so.debug symlinked /usr/lib/debug/usr/lib64/libpfm.so.4.2.0.debug to /usr/lib/debug/usr/lib64/libpfm.so.4.debug symlinked /usr/lib/debug/usr/lib64/libpfm.so.4.2.0.debug to /usr/lib/debug/usr/lib64/libpfm.so.debug symlinked /usr/lib/debug/usr/lib64/libpapi.so.4.2.1.0.debug to /usr/lib/debug/usr/lib64/libpapi.so.4.debug 4092 blocks + /usr/lib/rpm/check-buildroot ... ---------- RPM contents: ---------- $ rpm -qplv papi-4.2.1-0.20120209.el6.x86_64.rpm | grep /lib lrwxrwxrwx 1 root root 18 Feb 9 21:38 /usr/lib64/libpapi.so.4 -> libpapi.so.4.2.1.0 -rwxr-xr-x 1 root root 315872 Feb 9 21:38 /usr/lib64/libpapi.so.4.2.1 -rwxr-xr-x 1 root root 315880 Feb 9 21:38 /usr/lib64/libpapi.so.4.2.1.0 lrwxrwxrwx 1 root root 15 Feb 9 21:38 /usr/lib64/libpfm.so.4 -> libpfm.so.4.2.0 -rwxr-xr-x 1 root root 661752 Feb 9 21:38 /usr/lib64/libpfm.so.4.2.0 ---------- /jpo
papi-5.0.1-2 should address this issue. papi is now normally being built with: make %{?_smp_mflags}
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1587.html