The pcp build process internally invokes qmake, but it is not invoked in such a way that the qmake-driven build uses the proper RPM build flags. I asked about this matter on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WDU7IHZIUWENZAY4YRGU3OMHLB5CECOX/ There are other places where the flag injection fails. Some bits are built with -O0 -ggdb even: gcc -Wall -O0 -ggdb -fPIC -I../../src/include -I../../src/pmdas/perfevent -D_GNU_SOURCE -DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/rapl-interface.o ../../src/pmdas/perfevent/rapl-interface.c Running grep -E '^(gcc|g\+\+)' build.log | grep -E -v 'annobin|hardened-ld' on the build log should give you a good approximation where build flags are missing. Once you fix the flag passing, you will have to add this to the spec file: # pmcd has plugins, so it can't be linked with -z defs. %undefine _strict_symbol_defs_build
(In reply to Florian Weimer from comment #0) > The pcp build process internally invokes qmake, but it is not invoked in > such a way that the qmake-driven build uses the proper RPM build flags. I > asked about this matter on the devel list: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/WDU7IHZIUWENZAY4YRGU3OMHLB5CECOX/ > Great - thanks for the detailed discussion and follow-up, Florian. > [...] Some bits are built with -O0 -ggdb even: > > gcc -Wall -O0 -ggdb -fPIC -I../../src/include -I../../src/pmdas/perfevent > -D_GNU_SOURCE -DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/rapl-interface.o > ../../src/pmdas/perfevent/rapl-interface.c This is regression testing code below qa/perfevent/ - it's not shipped. > Running > > grep -E '^(gcc|g\+\+)' build.log | grep -E -v 'annobin|hardened-ld' > > on the build log should give you a good approximation where build flags are > missing. > > Once you fix the flag passing, you will have to add this to the spec file: > > # pmcd has plugins, so it can't be linked with -z defs. > %undefine _strict_symbol_defs_build OK, thanks. (in middle of some PTO at the moment, will look into it next week.)
(In reply to Nathan Scott from comment #1) > (In reply to Florian Weimer from comment #0) > > The pcp build process internally invokes qmake, but it is not invoked in > > such a way that the qmake-driven build uses the proper RPM build flags. I > > asked about this matter on the devel list: > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > > thread/WDU7IHZIUWENZAY4YRGU3OMHLB5CECOX/ > > > > Great - thanks for the detailed discussion and follow-up, Florian. > AIUI from just re-reading this discussion, there's nothing specific in the pcp.spec needed as a result of this ... please correct me if I'm wrong there. > > [...] Some bits are built with -O0 -ggdb even: > > > This is regression testing code below qa/perfevent/ - it's not shipped. > > > Running > > > > grep -E '^(gcc|g\+\+)' build.log | grep -E -v 'annobin|hardened-ld' > > > > on the build log should give you a good approximation where build flags are > > missing. > > The cc/ld lines from this specific test code can be excluded via: grep -E '^(gcc|g\+\+)' build.log | grep -E -v 'annobin|hardened-ld' | grep -E -v 'fakefs|mock_pfm' With that, I see no other bad lines in the rawhide pcp build. I was expecting some Qt-related lines, but I guess that's been resolved outside of pcp.spec as mentioned above. > > Once you fix the flag passing, you will have to add this to the spec file: > > > > # pmcd has plugins, so it can't be linked with -z defs. > > %undefine _strict_symbol_defs_build > I expected to see a rawhide build failure as a result of the global introduction of -z defs, but I'm not seeing one ... https://koji.fedoraproject.org/koji/taskinfo?taskID=24422358 It seems like -z defs is no longer being enabled in rawhide builds - is that correct / expected at this stage? When it comes back, the above %undefine looks a little broad for all of pcp - I have a patch to disable it in (what I think are) just the spots needed. cheers.
(In reply to Nathan Scott from comment #2) > (In reply to Nathan Scott from comment #1) > > (In reply to Florian Weimer from comment #0) > > > The pcp build process internally invokes qmake, but it is not invoked in > > > such a way that the qmake-driven build uses the proper RPM build flags. I > > > asked about this matter on the devel list: > > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > > > thread/WDU7IHZIUWENZAY4YRGU3OMHLB5CECOX/ > > > > > > > Great - thanks for the detailed discussion and follow-up, Florian. > > > > AIUI from just re-reading this discussion, there's nothing specific > in the pcp.spec needed as a result of this ... please correct me if > I'm wrong there. It is your responsibility to call qmake in such a way that the build flags are injected properly. The thread discusses ways to make it easier, but you'll still have to make a changes to the pcp build. > With that, I see no other bad lines in the rawhide pcp build. I was > expecting some Qt-related lines, but I guess that's been resolved outside of > pcp.spec as mentioned above. I'm rebuilding pcp build dependencies, so that we can try to build pcp again in current rawhide. As far as I can tell, the problem persists, and parts of pcp-3.12.2-4.fc28 (that end up as installed programs) definitely weren't built with the intended build flags. Please also fix the test suite to build with the right flags because it ships in RPMs. Otherwise, I have to whitelist it manually. > It seems like -z defs is no longer being enabled in rawhide builds - is that > correct / expected at this stage? Yes, it's already been disabled. > When it comes back, the above %undefine looks a little broad for all of pcp > - I have a patch to disable it in (what I think are) just the spots needed. You can turn it on if you want, sure.
I got pcp to build again in rawhide and see this: g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I../include -I../libpcp_qed/src -I../libpcp_qmc/src -I../libpcp_qwt/src -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtPrintSupport -isystem /usr/include/qt5/QtSvg -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtCore -I. -isystem /usr/include/libdrm -I. -I/usr/lib64/qt5/mkspecs/linux-g++ -o qrc_pmchart.o qrc_pmchart.cpp https://koji.fedoraproject.org/koji/taskinfo?taskID=24567813 So the build flags injection for qmake definitely does not work.
(In reply to Florian Weimer from comment #3) > (In reply to Nathan Scott from comment #2) > > AIUI from just re-reading this discussion, there's nothing specific > > in the pcp.spec needed as a result of this ... please correct me if > > I'm wrong there. > > It is your responsibility to call qmake in such a way that the build flags > are injected properly. The thread discusses ways to make it easier, but > you'll still have to make a changes to the pcp build. OK, will have to look more deeply into that. > Please also fix the test suite to build with the right flags because it > ships in RPMs. Otherwise, I have to whitelist it manually. I have a patch to make those test programs honour CFLAGS now, will queue it up for the next PCP upstream release (within a couple of weeks) & try to resolve these other issues before then too. Thanks Florian.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Would be nice to get this fixed.
First round of fixes has been merged upstream, the qmake aspects remain - Dave Brolley has kindly offered to take this remaining effort on. cheers.
(In reply to Florian Weimer from comment #4) > I got pcp to build again in rawhide and see this: > > g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG > -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB > -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I../include -I../libpcp_qed/src > -I../libpcp_qmc/src -I../libpcp_qwt/src -isystem /usr/include/qt5 -isystem > /usr/include/qt5/QtPrintSupport -isystem /usr/include/qt5/QtSvg -isystem > /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem > /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtCore -I. -isystem > /usr/include/libdrm -I. -I/usr/lib64/qt5/mkspecs/linux-g++ -o qrc_pmchart.o > qrc_pmchart.cpp > > https://koji.fedoraproject.org/koji/taskinfo?taskID=24567813 > > So the build flags injection for qmake definitely does not work. Hi Florian. I'm just coming on board with this problem. I've reproduced a build containing this snippet of the build log for pmchart.cpp. Which flag(s) above tell you that the correct flags are not being passed through to qmake? Similarly, which flags(s) are missing? How are you setting those flags? Thanks, Dave
You can look at the CFLAGS/CXXFLAGS/LDFLAGS settings shown early in the build log. These flags show up for all compiler and linker invocations throughout the build. Please do not hard-code the flags, though. See https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md for information on RPM macros and environment variables provided by the build environment.
Thanks. I read though the various discussions in this bug. - pcp.spec is already using the %configure macro, and the build logs confirm that CFLAGS, CXXFLAGS and LDFLAGS are being set in the %build fragment. - the %_qt5_qmake_flags macro sets some related variables, but none that are picked up by qmake. - commit 54a9d814c67c3967d4948812f2f36bc3695d8a29 at https://github.com/dbrolley/pcp build-flags contains changes which set QMAKE_CFLAGS, QMAKE_CXXFLAGS and QMAKE_LFLAGS based on CFLAGS, CXXFLAGS and LDFLAGS respectively for each place in the build which uses qmake. I have verified that this passes these flags down into the qmake builds. I am still seeing 3 places in the build where these flags are still not being injected: src/perl/MMV src/pmdas/mmv src/pmieconf
My mistake. The builds of the three subdirectories above are, in fact, picking up the build flags. https://kojipkgs.fedoraproject.org//work/tasks/2376/26172376/build.log Pending review, the commit in Comment 11 will appear upstream shortly.
commit 54a9d814c67c3967d4948812f2f36bc3695d8a29 has now been merged upstream
pcp-4.0.2-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6512e2424f
pcp-4.0.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-33d59f9a5f
pcp-4.0.2-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bfd50f6638
pcp-4.0.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-33d59f9a5f
pcp-4.0.2-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6512e2424f
pcp-4.0.2-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-bfd50f6638
pcp-4.0.2-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
pcp-4.1.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb77e69f1
pcp-4.1.0-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e351b52702
pcp-4.1.0-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e351b52702
pcp-4.1.0-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb77e69f1
pcp-4.1.0-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
pcp-4.1.0-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.