Bug 1700435
| Summary: | Compilation with QT5 requires "-fPIC" and not including it returns an error in /usr/include/qt5/QtCore/qglobal.h:1177:4 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Kyle Walker <kwalker> |
| Component: | qt5-qtbase | Assignee: | Jan Grulich <jgrulich> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.0 | CC: | fweimer, i, jgrulich, vanhoof |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-30 16:10:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
1) It's an upstream decision to use -fPIC 2) Isn't every single RHEL 8 package build with -fPIC (same for Fedora starting Fedora 23), because some flags are forced during the build and -fPIC seems to be one of them. Check /usr/lib/rpm/redhat/redhat-hardened-cc1. @Jan, Yep, it is an upstream decision to use -fPIC and to default to -reduce-relocations as far as I can tell. I believe you are correct as well that all packages we build/ship use -fPIC. That being said, it seems like the request here falls in between. The end user is attempting to avoid the overhead of -fPIC, and so want to build without the flag. It might be a naive approach, but since they are incurring the risks associated, it seems like a valid request. It seems rather arbitrary to _force_ end users to make use of -fPIE and/or -fPIC for all compilations. The Qt bug pretty well explains why -fPIC is inforced, according to what I read the only option is to use -fPIE or -FPIC when -reduce-relocation is used, but starting with GCC5 the only option for Qt is -fPIC. The request in the case is whether Qt5 can be build without "-fPIC" so the resolution is no, it can't because it's what we default to for all packages in RHEL. @Jan,
> The request in the case is whether Qt5 can be build without "-fPIC" so the
> resolution is no, it can't because it's what we default to for all
> packages in RHEL.
I don't think that is the entire request. The user is just looking for a way to build their applications against the qt5 implementation we ship, but without "-fPIC". Can you speak to the use of "-reduce-relocations" in our build? It seems that the flag, which is driving this error, is not without controversy. Looking back at our packaging, which seems like it is largely based off of the upstream Fedora release, it looks as though it has been added and removed over time.
<snip>
* Sun Dec 13 2015 Helio Chissini de Castro <helio> - 5.6.0-0.10
- We're back to gold linker
- Remove reduce relocations
<snip>
* Wed May 21 2014 Rex Dieter <rdieter> 5.3.0-2
- limit -reduce-relocations to %%ix86 x86_64 archs (QTBUG-36129)
<snip>
We currently seem to get this option enabled by default, since we don't interact with it directly in the specfile. However, building with "-no-reduce-relocations" means no more error:
<snip>
# awk '/configure \\/,/^$/' rpmbuild/SPECS/qt5-qtbase.spec
./configure \
-verbose \
-confirm-license \
-opensource \
-prefix %{_qt5_prefix} \
-archdatadir %{_qt5_archdatadir} \
-bindir %{_qt5_bindir} \
-libdir %{_qt5_libdir} \
-libexecdir %{_qt5_libexecdir} \
-datadir %{_qt5_datadir} \
-docdir %{_qt5_docdir} \
-examplesdir %{_qt5_examplesdir} \
-headerdir %{_qt5_headerdir} \
-importdir %{_qt5_importdir} \
-plugindir %{_qt5_plugindir} \
-sysconfdir %{_qt5_sysconfdir} \
-translationdir %{_qt5_translationdir} \
-platform %{platform} \
-release \
-shared \
-accessibility \
%{?dbus}%{!?dbus:-dbus-runtime} \
-fontconfig \
-glib \
-gtk \
%{?ibase} \
-icu \
%{?journald} \
-optimized-qmake \
%{?openssl} \
%{!?examples:-nomake examples} \
%{!?tests:-nomake tests} \
-no-pch \
-no-rpath \
-no-separate-debug-info \
-no-strip \
-system-libjpeg \
-system-libpng \
%{?harfbuzz} \
%{?pcre} \
%{?sqlite} \
%{?tds} \
%{?xcb} \
%{?xkbcommon} \
-system-zlib \
%{?use_gold_linker} \
-no-directfb \
-no-reduce-relocations \
QMAKE_CFLAGS_RELEASE="${CFLAGS:-$RPM_OPT_FLAGS}" \
QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS:-$RPM_OPT_FLAGS}" \
QMAKE_LFLAGS_RELEASE="${LDFLAGS:-$RPM_LD_FLAGS}"
<snip>
# gcc -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -lstdc++ -lQt5Core -lQt5Widgets testapp.cpp
# echo $?
0
# gcc -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -lstdc++ -lQt5Core -fPIC -lQt5Widgets testapp.cpp
# echo $?
0
I'm sure there is some facet I'm missing, but it looks like you _must_have_ "-fPIC" if you build with -reduce-relocations. With "-no-reduce-relocations", you get the option to build with "-fPIC" or without. Is there any technical reason why we can't simply disable the flag in our builds?
I'm not sure it's that easy, "-reduce-relocations" is used to make compilator to use "-Bsymbolic-functions" which from I read here [1] makes Qt library to load faster, I'm also not sure if disabling it will not force us to rebuild everything what was build against Qt using it. I'm also not fan of going against upstream defaults just because a customer wants to. If we go this way, we might also find another customer later who wants the oposit. @Florian, can you share your opinion on this? Because I'm not completely sure how these things/options work and what are the downsides. [1] - https://wiki.qt.io/Performance_Tip_Startup_Time Only one ELF object in the entire program can use direct bindings. For a default toolchain, following the ELF specification, this is the main program. However, Qt wants one of its dynamic shared objects to serve in that role. This means that the main program cannot use direct bindings, hence the -fPIC requirement with the current toolchain. (Note that I think this not portable: A link editor could still relax the PIC relocations to direct bindings.) Unfortunately, as Jakub explained on the GCC bug, Qt's shared objects are not compliant with the ELF specification. I'm not sure what can be done here. I think a proper solution (that doesn't force -fPIC on applications and keeps the optimization for the Qt library) would require per-symbol annotations in the Qt sources (e.g., hidden symbols and carefully avoiding inline functions in some places). This could be implemented with the toolchain as it exists today, but it requires significant work in upstream Qt. There is not much to complain on Qt side. Non-interposition-by-default is what Mach-O and Windows worlds do. -Bsymbolic-functions is pretty much justified, unless your -fno-pic code wants to take the address of a function and the toolchain doesn't emit GOT relocation and Qt behaves incorrectly if the pointer equality is somehow significant (which appears to be the case). I have taken a quick look at the upstream discussion https://bugreports.qt.io/browse/QTBUG-36129 which seems to be related to copy relocations. I left a comment there. It was due to a GCC x86-64 decision which should really be reconsidered today (HAVE_LD_PIE_COPYRELOC=1). No other arch should be constrained by the unfortunate GCC x86-64 default (even x86-32 is good as well; Clang has always been good). |
Description of problem: Attempts to build QT5 applications without "-fPIC" result in the following error: In file included from /usr/include/qt5/QtGui/qtguiglobal.h:43, from /usr/include/qt5/QtWidgets/qtwidgetsglobal.h:43, from /usr/include/qt5/QtWidgets/qapplication.h:43, from /usr/include/qt5/QtWidgets/QApplication:1, from a.cpp:1: /usr/include/qt5/QtCore/qglobal.h:1177:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)." # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ ^~~~~ Version-Release number of selected component (if applicable): qt5-qtbase-5.11.1-5.el8.x86_64 How reproducible: Easily Steps to Reproduce: 1. Create a simple test application <code> #include <QApplication> #include <QPushButton> int main(int argc, char **argv) { QApplication app (argc, argv); QPushButton button ("Hello world !"); button.show(); return app.exec(); } </code> 2. Compile the above using the following, explicitly without the "-fPIC" flag: # gcc -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -lstdc++ -lQt5Core -lQt5Widgets a.cpp Actual results: # gcc -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -lstdc++ -lQt5Core -lQt5Widgets a.cpp In file included from /usr/include/qt5/QtGui/qtguiglobal.h:43, from /usr/include/qt5/QtWidgets/qtwidgetsglobal.h:43, from /usr/include/qt5/QtWidgets/qapplication.h:43, from /usr/include/qt5/QtWidgets/QApplication:1, from a.cpp:1: /usr/include/qt5/QtCore/qglobal.h:1177:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)." # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ ^~~~~ # echo $? 1 Expected results: # gcc -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -lstdc++ -lQt5Core -lQt5Widgets a.cpp # echo $? 0 Additional info: The issue seems to have been extensively discussed upstream [^1][^2]. The discussion seems to be centered around the use of PIE vs PIC. In this instance, the end intention is to use neither. This is primarily to avoid the performance impact and overhead of PIC. The issue is observed on RHEL 8.0 Beta, [^1]: [QTBUG-45755] Some Qt apps crashs if they are compiled with gcc5 - Qt Bug Tracker - https://bugreports.qt.io/browse/QTBUG-45755 [^2]: [Development] Qt, fPIE, fPIC and changes coming in Qt 5.4.2 - https://lists.qt-project.org/pipermail/development/2015-May/021557.html