Bug 1279265 - qmake and others require redhat-hardened-cc1 and break compilation
qmake and others require redhat-hardened-cc1 and break compilation
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
Depends On: 1301086 1303288 1303289 1303444 1306463 1306465 1352020
Blocks: 1289759
  Show dependency treegraph
Reported: 2015-11-08 18:25 EST by C6563
Modified: 2016-12-08 06:07 EST (History)
11 users (show)

See Also:
Fixed In Version: qt-4.8.7-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1289759 (view as bug list)
Last Closed: 2016-04-15 11:38:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description C6563 2015-11-08 18:25:37 EST
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"

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.
Comment 1 Rex Dieter 2015-11-08 22:36:51 EST
Hrm, an interesting problem indeed, a side-effect of default compiler flags changing to accommodate this new f23 feature:
Comment 2 C6563 2015-11-09 06:48:50 EST
For example, archlinux default usr/lib64/qt4/mkspecs/linux-g++/qmake.conf is:

and debian just to:
Comment 3 C6563 2015-11-09 06:57:15 EST
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).
Comment 4 Rex Dieter 2015-11-09 08:26:37 EST
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.
Comment 5 C6563 2015-11-09 08:34:22 EST
"-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1" flag is also present in my system for:


and a few others. So the probability of breaking user side compilations is high for more projects than qt
Comment 6 Rex Dieter 2015-11-25 08:44:15 EST
I'm going to implement option 3 in the short term, while we ponder possible better long-term solutions.rdieter@math.unl.edu
Comment 7 Pavel Raiskup 2015-12-08 10:55:42 EST
I'm not sure how this is related to libtool, can I help somehow?
Comment 8 Rex Dieter 2015-12-08 13:30:09 EST
It's not related to libtool, I'll remove that from the summary.
Comment 9 Rex Dieter 2015-12-08 13:32:33 EST
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.
Comment 10 Fedora Update System 2015-12-08 15:59:38 EST
qt-4.8.7-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-4bb606c54b
Comment 11 Fedora Update System 2015-12-09 23:56:14 EST
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
Comment 12 Fedora Update System 2015-12-12 23:22:40 EST
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.
Comment 13 Ville Skyttä 2016-01-18 04:25:00 EST
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.
Comment 14 Rex Dieter 2016-01-18 08:34:40 EST
Good point, will do.
Comment 16 Rex Dieter 2016-01-18 09:36:55 EST
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.
Comment 17 Rex Dieter 2016-01-18 11:02:11 EST
psi should be fixed now too.
Comment 18 Raphael Groner 2016-01-18 13:03:50 EST
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.
Comment 19 Ville Skyttä 2016-01-18 15:31:43 EST
(In reply to Rex Dieter from comment #15)
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.

Excellent, thank you.
Comment 20 Kevin Kofler 2016-01-19 22:00:00 EST
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.
Comment 21 Ville Skyttä 2016-01-31 14:23:04 EST
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.
Comment 22 Rex Dieter 2016-01-31 15:23:28 EST

though ouch, 108!  Not enough maintainers read the fedora-devel thread it seems :(
Comment 23 Ville Skyttä 2016-01-31 15:34:30 EST
Right; the number of specfiles containing the string qmake_qt4 is 32...
Comment 24 C6563 2016-03-01 18:07:19 EST
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?
Comment 25 Rex Dieter 2016-03-01 19:03:12 EST
Yes, seems wxWidgets suffers from a similar issues as Qt
Comment 26 Rex Dieter 2016-04-15 11:38:38 EDT
Closing, since qt itself to address the orginal reported issue since

* Wed Nov 25 2015 Rex Dieter <rdieter@fedoraproject.org> 1:4.8.7-5
- -devel: Requires: redhat-rpm-config (#1279265)

and there are no longer any open bugs linked here either

Note You need to log in before you can comment on or make changes to this bug.