Description of problem: I was developing a qt project before I upgraded to Fedora 23. After Fedora 23 I noticed that my project stopped compiling and I decided to make some tests. Using 2 virtual machines: VM A: Fedora 22 clean and updated installation VM B: Fedora 23 clean and updated installation In both dnf install qt-devel and try to build my project. In Fedora 22: compiles and runs fine In Fedora 23: it does not. missing file "redhat-hardened-cc1" After I installed "redhat-rpm-config" it does compile but does not link. After further investigation I noticed that Fedora 23 is addding too much flags to CFLAGS, CXXFLAGS, LFLAGS whereas Fedora 23 was not. The problem is that Fedora 23 defaults to these flags present in /usr/lib64/qt4/mkspecs/linux-g++/qmake.conf: "QMAKE_CFLAGS_RELEASE += -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic" Where Fedora 22 had: "QMAKE_CFLAGS_RELEASE += -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" So, two questions here: 1) Should every qmake4-qt foo.pro depend on redhat-hardened-cc1? If so, it should be added to qt-devel dnf dependency. (and greping /usr a few python2.4 and 3.4 also have this dependency" 2) It is breaking compilation for users. A quick google search returns a few new cases like mine. and a note: 3) /usr/bin/libtool also has same problem at "LTCFLAGS" == Note: for users having this problem, setting QMAKE_CXXFLAGS, QMAKE_CXXFLAGS_RELEASE, QMAKE_CFLAGS, QMAKE_CFLAGS_RELEASE, QMAKE_LFLAGS, QMAKE_LFLAGS_RELEASE in qt project file helped me to clear system wide FLAGS that break compilations.
Hrm, an interesting problem indeed, a side-effect of default compiler flags changing to accommodate this new f23 feature: https://fedoraproject.org/wiki/Changes/Harden_All_Packages
For example, archlinux default usr/lib64/qt4/mkspecs/linux-g++/qmake.conf is: QMAKE_CFLAGS = -m64 and debian just to: QMAKE_CFLAGS += -pipe
It looks like https://bugzilla.redhat.com/show_bug.cgi?id=1197501 is related. My compiler also suggests to enable -fPic when linking fails (with does not solve the problem).
Options in my own preference: 1. revert putting %optflags into QMAKE_CFLAGS_RELEASE anymore, we do have usable %qmake_qt4 and %qmake_qt5 macros that do that for us for package builds now 2. strip hardening-related flags from QMAKE_CFLAGS_RELEASE (in effect, use same flags as f22) 3. add dep on redhat-rpm-config 1 is probably the cleanest long-term, but also the most invasive, we may be able to implement that for future releases (f24+) only, since it probably ought to include auditing all qmake-based fedora packages to help ensure no regressions. As an aside: If we decide on any option other than 1, I noticed a possible related problem in that we're not injecting %{__global_ldflags} anywhere (into QMAKE_LFLAGS_RELEASE?) yet either.
"-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" flag is also present in my system for: /usr/lib64/python2.7/config/Makefile /usr/bin/bashbug-64 /usr/lib64/python3.4/_sysconfigdata.py /usr/lib64/python3.4/config-3.4m/Makefile /usr/lib64/python2.7/site-packages/sipconfig.py /usr/lib64/mysql/INFO_BIN and a few others. So the probability of breaking user side compilations is high for more projects than qt
I'm going to implement option 3 in the short term, while we ponder possible better long-term solutions.rdieter.edu
I'm not sure how this is related to libtool, can I help somehow?
It's not related to libtool, I'll remove that from the summary.
Ah, I see now, in /usr/bin/libtool is embedded, # LTCC compiler flags. LTCFLAGS="-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC" probably should be a separate bug for this.
qt-4.8.7-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-4bb606c54b
qt-4.8.7-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update qt' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4bb606c54b
qt-4.8.7-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Based on briefly looking into git, option 1 from comment 4 has been implemented now in 4.8.7-6. And I guess as a result of that, the latest rawhide builds (haven't checked other distro versions) of at least fuelmanager, opencsg, openscad, psi, and yubikey-personalization-gui have been done without $RPM_OPT_FLAGS. The two most prominent problems with this are that the distro security related compiler flags have not been applied, and the built debuginfos are useless. If there has been an announcement about this, I haven't seen it, and seems like others whose packages are affected have missed it as well. Please announce the change as well as the steps maintainers need to take with their packages in order to not cause the compiler flag regressions, preferably along with a list of affected packages. Changes like these need better communication.
Good point, will do.
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/6TLCJFMMVPYHJKDL4XZYUEO66GYM64I7/
I went and fixed most of those pkgs you mentioned, minus psi, because "yay, custom buildsystem", so that one will require a little more work.
psi should be fixed now too.
We're working on an implementation of a more common build system based on cmake for psi-plus (successor of psi) with help from upstream, see bug #1292095.
(In reply to Rex Dieter from comment #15) > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject. > org/message/6TLCJFMMVPYHJKDL4XZYUEO66GYM64I7/ Excellent, thank you.
If the packages had been compliant to the Qt packaging best practices to begin with, they would not have been affected by this change. Packages should NOT call qmake (or qmake-qt4, qmake-qt5) directly (no more than they should run ./configure directly for autoconf), that's what the RPM macros are for.
The list of packages likely affected by this is quite large, so it'd be better to concentrate some work in fixing them instead of waiting issues to surface on next builds (and possibly falling through the cracks). Here's one way to generate the list; there are some false positives but the order of magnitude should be correct: wget http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz && \ tar xf rpm-specs-latest.tar.xz && \ grep -Erl '_qt4_qmake|qmake-qt4' rpm-specs \ | sort Currently that output has 108 lines. It would be also good to prepare for the same thing for Qt 5 before it actually happens; the corresponding grep for it has 37 lines at the moment.
Thanks! though ouch, 108! Not enough maintainers read the fedora-devel thread it seems :(
Right; the number of specfiles containing the string qmake_qt4 is 32...
I found another broken compilation, this time because wxWidgets. $ cd /usr $ rep -r redhat-hardened-ld (...) lib64/wx/config/gtk2-unicode-release-2.8: echo $_ldflags "-pthread -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld " $_rpath $wx_libs "" (...) with the same type of error: bin/ld: CMakeFiles/colorgui.dir/src/cmvision.cc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC CMakeFiles/colorgui.dir/src/cmvision.cc.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[2]: *** [/home/luminoso/catkin_ws/devel/lib/cmvision/colorgui] Error 1 this time I already suspected the source. Should I open a new bug report?
Yes, seems wxWidgets suffers from a similar issues as Qt
Closing, since qt itself to address the orginal reported issue since * Wed Nov 25 2015 Rex Dieter <rdieter> 1:4.8.7-5 - -devel: Requires: redhat-rpm-config (#1279265) and there are no longer any open bugs linked here either