[Development] QT_FEATURE_reduce_relocations breaking executables that mention qApp?

[Thiago Macieira]

On Wednesday, 3 December 2025 08:51:53 Pacific Standard Time Stephan Bergmann 
wrote:
> I wonder what the intended use and implementation of the (apparently
> enabled by default) QT_FEATURE_reduce_relocations is (in Qt 6.10 on
> Linux, at least):

It's been enabled by default since 4.x.

The problem is that it runs into toolchain issues left and right. This was 
finally fixed with ELF protected visibility and GCC's option -mno-direct-extern-
access and Clang's -fno-direct-access-external-data a few years ago. This is 
now the recommended way of writing libraries on Linux and I plan to enforce it 
by default in Qt 7.

I can't do that right now because of legacy content support.

> In the comment at
> <https://github.com/CollaboraOnline/online/issues/13683#issuecomment-3600826
> 333> "Crash on startup CODA-Q" I have a Linux executable that links against
> libQt6Core.so.6 and some other Qt6 shared libraries, and that in its source
> code mentions the qApp macro (and thus includes a copy of the inline
> function QCoreApplication::instance in the executable, and thus exports the
> symbol _ZN16QCoreApplication4selfE for the
> QCoreApplication::self static data member from the executable).

Yup, this is the most visible issue, but not the most scary one. It's the 
invisible ones, that don't cause immediate crashes, that are scariest.

> When I run that executable in the org.kde.Platform/x86_64/6.10 flatpak
> runtime (as distributed on Flathub), it immediately SIGSEGV's.  I
> tracked this down to libQt6Core.so.6 erroneously using its own local
> copy of _ZN16QCoreApplication4selfE, while all the other shared
> libraries and the executable use the copy of _ZN16QCoreApplication4selfE
> from the executable (as intended).  That way,
> QCoreApplicationPrivate::init (in libQt6Core.so.6) assigns to
> _ZN16QCoreApplication4selfE in libQt6Core.so.6, but the content of
> _ZN16QCoreApplication4selfE in the executable will stay null, and as
> soon as code from any of the other Qt6 shared libraries or the
> executable dereferences QCoreApplication::self, a null-pointer SIGSEGV
> ensues.

QtCore is right and all the other ones are wrong. They should have accessed 
the QtCore copy.

> When I run that executable against qt6-qtbase-6.10.1-1.fc43.x86_64 on
> Fedora 43 (outside of a flatpak), it happens to work.  I tracked this
> difference in behavior down to the Fedora RPM being built with an
> explicit -DQT_FEATURE_reduce_relocations=OFF (which is present ever
> since
> <https://src.fedoraproject.org/rpms/qt6-qtbase/c/2ad9816328732397e68019041b9
> 1e857e2fc88b1> "Initial package", so the rationale for including it there
> may be lost to history; it got replaced with
> -DFEATURE_reduce_relocations=OFF in
> <https://src.fedoraproject.org/rpms/qt6-qtbase/c/075288afadb8993e46c1029489
> b506fbb6885383> "Use -DFEATURE instead -DQT_FEATURE for additional
> compatibility
> checks", for whatever reason), while the flatpak runtime apparently uses
> an implicit QT_FEATURE_reduce_relocations=ON:

That's the legacy problem. Some content was compiled without the flag, which 
meant that we can't turn it on. Some Linux distros have then opted to turn the 
feature off, making Qt slower and larger, for the benefit of application and 
library code that failed to use the best practice for making libraries.

> > -Wl,--dynamic-list=/run/build-runtime/qt6-qtbase/src/corelib/QtCore.dynlis
> > t
> 
> where the content of that QtCore.dynlist is

The dynlist functionality is irrelevant to this. It's also broken. See
https://codereview.qt-project.org/c/qt/qtbase/+/666538. I won't proceed on 
that one until there are complaints (letting sleeping dogs lie). KDAB people 
might be interested in this.

> I wonder what the intended use of that QT_FEATURE_reduce_relocations is,
> given that it apparently leads to broken applications.  Is it "just"
> that the apparent behavior of ld's --dynamic-list option is not as
> anticipated by the Qt developers (and there should be something like a
> "global:*;" fallback section in qtbase's src/corelib/QtCore.dynlist.in)?
>   Or is the recipe for the org.kde.Platform flatpak runtime broken, and
> it should have been built with an explicit
> -DQT_FEATURE_reduce_relocations=OFF?  Or am I missing something else?

Like I said above, this is a result of 15 years of fighting the toolchain to 
get them to optimise for the largest volume of code being executed: libraries. 
The recommendations from Uli's DSO HOWTO[1] are very hard to apply to C++, so 
we needed toolchain help, which we failed to get until I managed to work with 
H.J. a few years ago and explain the problem. That resulted in the *correct* 
implementation, of the no-direct-extern-access feature.

All the previous attempts are broken in one way or another. I do not plan on 
touching any of the older attempts.

[1] https://akkadia.org/drepper/dsohowto.pdf

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20251203/29f286f8/attachment-0001.bin>