The -mno-direct-extern-access tells the compiler and linker that
references to symbols outside this ELF module mustn't be direct and must
instead always go through the GOT or PLT (the PLT can additionally be
disabled with -fno-plt). The ELF protected visibility tells the compiler
and linker that this symbol is present in the dynamic symbol table as an
export, but it cannot be interposed by another ELF module.
This option is required for user code to link properly to Qt, otherwise
they will get linker errors (assuming GNU binutils >= 2.39) or runtime
failures (glibc >= 2.35). Both versions of glibc and binutils are older
than GCC 12, so it's a safe assumption they are in use and downgrading
the toolchain or libc is not supported. Adding this option to the
compilation is assured for CMake and qmake-based projects.
For example, all accessess to QCoreApplication::self in QtCore, after
this change and with GCC 12 are relocation-free and direct:
000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>:
13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self>
13ebf8: setne %al
13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]>
13ec01: ret
Meanwhile, accesses to the same variable in other modules are indirect
via the GOT:
66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6>
66657: cmpq $0x0,(%rax)
This replaces the -Bsymbolic and -Bsymbolic-functions (broken)
functionality that Qt has been using or attempting to use since ~2006.
See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128
Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After the update to the CMake based build system the ability to
generate pkgconfig files, like it was with QMake, was lost.
This patch adds pkgconfig generation again via a new internal command
named qt_internal_export_pkg_config_file.
The functionality of this command consists in checking if the target
is internal. Then gets the compile definitions. It performs a search
for dependencies that is somewhat similar to
qt_get_direct_module_dependencies, although it won't recurse down for
more deps. Each dependency is then again, checked if it's internal or
has a public interface. Later these deps get deduplicated and lastly
a pkgconfig file is filled.
The resulting pkgconfig files of many of the Qt6 packages were
validated via invocations of `pkg-config --validate` and
`pkg-config --simulate` commands and later used to build local
projects plus tests that use the pkg-config provided details at
compilation time.
Although it has some limitations, with qt_internal_add_qml_module if
it specifies non-public deps these won't be listed and with non-Qt
requirements, notably in static builds, not being appended to the
PkgConfig file.
Task-number: QTBUG-86080
Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since platform definition directory is used as an interface include
path of the Qt::Platform target, it makes sense to define it for this
target only. Also the definition of cached values that contain
path to platform definition looks redundand.
The definition of QT_PLATFORM_DEFINITION_DIR from command line
doesn't make any sense since build procedure doesn't take it into
account when installing mkspecs and the use if the user-provided
QT_PLATFORM_DEFINITION_DIR value as a Qt::Platform include directory
causes inconsistency in the prefixed builds. INSTALL_MKSPECSDIR
and QT_QMAKE_TARGET_MKSPEC should be used instead.
Change-Id: I3636c57b835cb84511a358a0910cc482c5fbd81e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Platform definition directory is defined when building qtbase.
Depending on the build type (prefixed/non-prefixed) it should point:
- To the source directory when building prefixed qtbase.
- To the installation directory of the prefixed qtbase when building
consumer projects.
- To the build directory of non-prefixed qtbase when building
non-prefixed qtbase or consumer projects.
TODO: It is desirable to move the logic asssociated with Qt platform
definition to the qt_internal_setup_public_platform_target function.
Pick-to: 6.1 6.2
Fixes: QTBUG-94973
Change-Id: I8530613f9b2029834c66206bbdf02475528a4640
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After discussion we decided to opt-out the UNICODE definintion
behavior. To disable UNICODE in user projects the
qt6_disable_unicode_defines function could be used.
Amends 5b64e5950c
[ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on
WIN32 platforms by default for all cmake projects to reflect the
qmake behavior. Use qt6_disable_unicode_defines function to disable
the default unicode definitions.
Pick-to: 6.1
Fixes: QTBUG-93895
Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
