Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1279265 - qmake and others require redhat-hardened-cc1 and break compilation
Summary: qmake and others require redhat-hardened-cc1 and break compilation
Alias: None
Product: Fedora
Classification: Fedora
Component: qt
Version: 23
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On: 1301086 1303288 1303289 1303444 1306463 1306465 1352020
Blocks: 1289759
TreeView+ depends on / blocked
Reported: 2015-11-08 23:25 UTC by luminoso
Modified: 2016-12-08 11:07 UTC (History)
11 users (show)

Fixed In Version: qt-4.8.7-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1289759 (view as bug list)
Last Closed: 2016-04-15 15:38:38 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1218294 0 unspecified CLOSED Split hardened-cc1 and hardened-ld to a subpackage 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1292095 0 medium CLOSED [Tracker, RFE] CMake support in psi* packages (psi-plus mostly) and with Qt5 2021-02-22 00:41:40 UTC

Internal Links: 1218294 1292095

Description luminoso 2015-11-08 23:25:37 UTC
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 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-09 03:36:51 UTC
Hrm, an interesting problem indeed, a side-effect of default compiler flags changing to accommodate this new f23 feature:

Comment 2 luminoso 2015-11-09 11:48:50 UTC
For example, archlinux default usr/lib64/qt4/mkspecs/linux-g++/qmake.conf is:

and debian just to:

Comment 3 luminoso 2015-11-09 11:57:15 UTC
It looks like 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 13:26:37 UTC
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 luminoso 2015-11-09 13:34:22 UTC
"-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 13:44:15 UTC
I'm going to implement option 3 in the short term, while we ponder possible better long-term

Comment 7 Pavel Raiskup 2015-12-08 15:55:42 UTC
I'm not sure how this is related to libtool, can I help somehow?

Comment 8 Rex Dieter 2015-12-08 18:30:09 UTC
It's not related to libtool, I'll remove that from the summary.

Comment 9 Rex Dieter 2015-12-08 18:32:33 UTC
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 20:59:38 UTC
qt-4.8.7-5.fc23 has been submitted as an update to Fedora 23.

Comment 11 Fedora Update System 2015-12-10 04:56:14 UTC
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:

Comment 12 Fedora Update System 2015-12-13 04:22:40 UTC
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 09:25:00 UTC
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 13:34:40 UTC
Good point, will do.

Comment 16 Rex Dieter 2016-01-18 14:36:55 UTC
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 16:02:11 UTC
psi should be fixed now too.

Comment 18 Raphael Groner 2016-01-18 18:03:50 UTC
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 20:31:43 UTC
(In reply to Rex Dieter from comment #15)

Excellent, thank you.

Comment 20 Kevin Kofler 2016-01-20 03:00:00 UTC
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 19:23:04 UTC
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 && \
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 20:23:28 UTC

though ouch, 108!  Not enough maintainers read the fedora-devel thread it seems :(

Comment 23 Ville Skyttä 2016-01-31 20:34:30 UTC
Right; the number of specfiles containing the string qmake_qt4 is 32...

Comment 24 luminoso 2016-03-01 23:07:19 UTC
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/ relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
CMakeFiles/colorgui.dir/src/ 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-02 00:03:12 UTC
Yes, seems wxWidgets suffers from a similar issues as Qt

Comment 26 Rex Dieter 2016-04-15 15:38:38 UTC
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

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