[Development] QT_FEATURE_reduce_relocations breaking executables that mention qApp?

[Stephan Bergmann]

On 12/3/25 21:51, Thiago Macieira wrote:
> On Wednesday, 3 December 2025 08:51:53 Pacific Standard Time Stephan Bergmann
> wrote:
>> 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.

So, if I get you right, you claim that my executable should be built in 
a way that it does not export _ZN16QCoreApplication4selfE and rather 
have that as undefined (so that the executable and all the other Qt 
shared libraries bind to the copy exported by QtCore)?  But I fail to 
find a way how to build the executable that way.