Re: Qt question: GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS

Ionen Wolkens <[email protected]> Wed, 22 Apr 2026 00:57:38 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<aehVQmlU6KR978q2@eversor>
On Wed, Apr 22, 2026 at 03:56:22AM +0000, Andrey Grozin wrote:
> On Sun, 19 Apr 2026, Ionen Wolkens wrote:
> > On Sun, Apr 19, 2026 at 05:13:26PM +0100, Sam James wrote:
> >> Andrey Grozin <[email protected]> writes:
> >>> It seems qtbase in Gentoo (and arch) is compiled in a way that makes
> >>> it incompatible with binary programs compiled for other distros.
> >> Qt upstream recommends we use this and I think they plan to make it the
> >> default for Qt 7. It improves load time.
> > Actually kind of surprised this is the first time I hear of this
> > considering we made the switch without rebuilding everything,
> > meaning packages built against regular Qt started using it without
> > a rebuild and didn't complain? Or am I missing something?
> >
> > Think there are other prebuilts using it too, like google-chrome's
> > qt6 plugin (is it broken?).
> >
> > Maybe it's something specifically with how this was built like
> > maybe it used a old binutils or something similar, not that we
> > can do much about it either way.
> I can try to contact the upstream and ask them to recompile this program. 
> But I need more information for preparing such a letter:
> 
> 1. What exactly is different in the way we compile qtbase and, say, 
> Ubuntu? (they definitely support Ubuntu)

This is the thing that we enable (Arch does too, maybe others esp.
distros that use or support building with LTO and haven't opted to
just disable it for Qt and revdeps), from qtbase's configure.cmake:

qt_feature("no_direct_extern_access" PRIVATE
    LABEL "Use protected visibility and -mno-direct-extern-access"
    CONDITION NOT WIN32 AND TEST_no_direct_extern_access
    AUTODETECT OFF
)
 
> 2. What exactly have they to do to recompile their (secret) sources to be 
> compatible with our Qt6? Does this require introducing some changes to the 
> sources, or is just recompiling with some changed flag(s) sufficient?

I don't know.

> 3. In the case they recompile, will the new binary remain compatible with 
> Ubuntu, Debian, RHEL? Or will 2 different binaries be necessary?

That would depend on what #2 needs, so I don't know either.

Like I noted, I find it curious that it is an issue considering that we
switched that option ON without rebuilding everything (meaning packages
built against a Qt that had it disabled were still fine). So there is
likely "something" but that'd need experimenting to figure out. Maybe
it's the toolchain, maybe it's due to using some old LTS version of
Qt to build with, or maybe it's the opposite and we just got lucky
during the switch... I wouldn't know, personally never heard of this
issue before.

Like Qt upstream mentions, if can't figure it out, it may be better to
just use the Qt libraries it was built with (bundled) if the source is
not provided. Assuming that upstream provides them, haven't checked.
-- 
ionen
signature.asc (application/pgp-signature, 525 B)