If QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS is ON then we generate
Windows scripts on Unix and vice versa. We always used the host
platforms line endings for generating the scripts. This leads to
Windows line endings in Unix scripts and vice versa.
Explicitly specify the line endings style when generating wrapper
scripts.
Fixes: QTBUG-102747
Pick-to: 6.2 6.3
Change-Id: I1603add46f276a5d91bbf0f103a261cdd84c343b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
qmake adds QMAKE_PRL_LIBS values on the link line after the currently
processed library. Because CMake adds resource object files into
QMAKE_PRL_LIBS, they end up on the link line after the library.
This causes issues on Linux with GNU ld and ld.gold, because the
linker discards symbols from the library which are then later referenced
by the object files.
Work around that by placing the path to the library directly into
QMAKE_PRL_LIBS after the resource object files.
This ensures the linker doesn't discard the symbols required by the
resource object files.
This means that each library encountered in qmake's LIBS variable will
be temporarily referenced twice in qmake's project state: once from
LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are
added. On the link line it will appear only once though, because qmake
does library deduplication during prl file processing, which only keeps
the last occurrence.
Amends 4ab5432081
Pick-to: 6.2 6.3
Fixes: QTBUG-103002
Change-Id: I97647b64de22b158424850915fee62b5fea5f995
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
JavaScripts's BigInt feature provides support for arbitrary-precision
integers. This makes it possible to represent 64-bit integers; the
standard JS Number type supports 32-bit integers only (or more
accurately 53-bit integers - see Number.MAX_SAFE_INTEGER).
Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t
to BigInt when interfacing with JavaScript code.
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
find_library does not always work because libatomic.so may be in a path
like /usr/lib/gcc/x86_64-linux-gnu/11/libatomic.so, which CMake does not
consider by default.
Pick-to: 6.3
Change-Id: I73a657c470efa4f84f8629bd531edfcac3b3a352
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unsetting CMAKE_STRIP and including CMakeFindBinUtils to find it again
is not safe, because CMakeFindBinUtils has logic to search for
additional tool names depending on the currently processed language.
The currently processed language is set in _CMAKE_PROCESSING_LANGUAGE
only when CMake is doing it's language introspection via
CMakeCXXCompiler.cmake.
This resulted in the build system finding a regular host-OS strip,
rather than an android specific llvm-strip when doing an Android
build, which then silently failed to strip the Android libraries
and caused us to ship big binaries.
Improve the strip wrapper creation in a few ways:
- Save the original strip value on first configuration
- Restore it if needed, without using CMakeFindBinUtils
- Don't apply the strip wrapper creation logic to Android,
we currently don't need it there
- Add some informational messages about which CMAKE_STRIP
ends up being used even if log-level is not DEBUG
- Fix a typo
Amends 39f657032b
Pick-to: 6.2 6.3
Fixes: QTBUG-103356
Task-number: QTBUG-101653
Change-Id: I23d98180446d5bb7628e783668f46e4e546ed700
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON.
When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set
QT_FORCE_BUILD_TOOLS. But this happened too late: after the
initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on
QT_FORCE_BUILD_TOOLS.
This amends commit acfbe3b779.
Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace BOOTSTRAP option with the single value CORE_LIBRARY argument
in qt_internal_add_tool and qt_internal_add_executable functions.
The introduced argument now may accept 'Bootstap' and 'None' values.
Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None'
to avoid any core library linking. This is useful for tools that need
to use the CMake deployment routines, but not require the Qt::Core
functionality.
Task-number: QTBUG-87480
Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, this was only supported when cross-compiling, but that's an
unnecessary limitation. Instead, make it possible to build the "host"
tools (notably qmake) even when they've been found elsewhere due to
QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH.
The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to
ON is useful for developers who touch content that ends up in the
bootstrap library.
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of
QT_FORCE_BUILD_TOOLS.
[ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been
deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in
combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from
a host Qt even for a non-cross build and still build the tools.
Fixes: QTBUG-99683
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise they will just use default compiler
Pick-to: 6.3
Change-Id: Id5813b99fbbb6b0d8b0ee658e06312b637a097c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt is configured with -platform linux-g++-32 , make sure
to add the -m32 compile options for all built targets.
On 64 bit host OSes that provide both 32 and 64 bit libraries
we need to exclude the 64 bit libraries from being picked up.
The locations of the libraries are distro-specific.
This change by default excludes the Ubuntu x86_64 libraries
paths.
Opt outs are provided, which when used, forces Qt builders to
specify their own ignore paths in a custom CMake toolchain file.
The compile option and default path exclusions are added to the
Qt-generated CMake toolchain file as well, so they are reused
when building other Qt repositories.
Note that there is no foolproof way to tell CMake to ignore all
x86_64 packages / libraries, even if CMake 3.23
CMAKE_IGNORE_PREFIX_PATH is used, because there might not be
a single sysroot to exclude.
Both x86 and x86_64 libraries can co-exist in the same sysroot,
e.g in /usr
One would have to list each package / library directory in
CMAKE_IGNORE_PATH manually.
Additionally, the PKG_CONFIG_LIBDIR environment variable is also set
to Ubuntu specific prefixes, to ensure that pkg_check_modules ->
pkg-config don't pickup x86_64 libraries.
Fixes: QTBUG-101963
Change-Id: Ib17c8d2cd0ba33b2cf748772245bcd558de9120c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Do build zlib as static 3rdparty library. This makes it easier to
disable warnings.
Pick-to: 6.3
Change-Id: I1db331b671b64e68d81c56b0df337983c3bbe7fa
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
message(STATUS) prints output to a buffered stdout, whereas
message(NOTICE) or just message() print to unbuffered stderr.
We use a mix of message() calls when printing the configuration
summary, which caused interleaved output.
Because CMake offers no message(FLUSH), we work around the issue
by calling execute_process(COMMAND -E echo " ") which does
call std::cout << s << std::flush;
We seem to have to do it twice, before and after the
detailed configuration summary is printed.
Pick-to: 6.2 6.3
Change-Id: Ibc075551fc0547073f0696477e54d9b9c1edca97
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When Qt is configured as relocatable,
QT_CONFIGURE_PREFIX_PATH_STR -> qt_configure_prefix_path_str ->
qt_prfxpath
is not used in relevant code paths.
Specifically qlibraryinfo.cpp getPrefix() uses getRelocatablePrefix()
instead of QT_CONFIGURE_PREFIX_PATH.
Thus, when Qt is configured as relocatable, set qt_prfxpath to an
empty string.
This avoids embedding a CI path like /home/qt/work/install into the
official packages, which makes reproducible builds a closer reality.
Change-Id: I9209b08e651ad0b7fdc4049df333e0978e05f1f5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
CMake has logic to rewrite build rpaths that contain
CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX.
This breaks running executables from the build directory, because
their build rpath will point to a location where the libraries might
not exist yet (we didn't install Qt yet).
Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so
that CMake does not do the rewriting anymore.
CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not
function scope, which is why
qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro
that is called from within each Qt internal function that creates
a target.
The workaround can be disabled by configuring with
-DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON
The downside of this workaround is that it breaks per-subdirectory
install rules like 'ninja src/gui/install'.
Regular global installation like 'ninja install' works fine.
This is similar to what we do for tests in
qt_set_up_fake_standalone_tests_install_prefix()
introduced by 20292250d4
The reason it's not as good for other target types is because in
contrast to tests, we do want to install them.
In case if someone does call `ninja src/gui/install' they will most
likely get a permission error, telling them it's not possible to
install into
/qt_fake_staging_prefix/
check_qt_internal_apply_staging_prefix_build_rpath_workaround
Fixes: QTBUG-102592
Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The change
0ec75f4b99
missed adding specialHTMLTargets for qmake
Also add warning to keep QtWasmHelpers in sync with qmake.conf
Change-Id: Idb363e77f0cecb4f125d3cb4f7507899149a3bac
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
There should be no need for CMake to add rpaths pointing to
directories outside of the build tree to the installed libraries.
All relevant install rpaths are handled by qt_apply_rpaths().
Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There were a few things that were not ported correctly.
Make sure to disable rpath manipulation if the rpath feature is
disabled.
Fix if(IS_ABSOLUTE) conditions to actually take values.
Don't embed bogus relative rpaths if the platform does not support
it. QNX is such a platform, it does not support $ORIGIN (at least from
my scouring of QNX documentation and manual testing via QEMU).
Handle the extra rpath case where they are relative, but the platform
does not support relative rpaths, by transforming them into absolute
ones.
Amends 67ee92f4d8
Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if
-extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX)
-developer-build (FEATURE_developer_build)
were specified, but
-prefix (CMAKE_INSTALL_PREFIX)
was not,
the build system would set the CMAKE_INSTALL_PREFIX to the
qtbase build dir.
Then, if targeting desktop, this would be considered a non-prefix
build (ninja install would refuse to work), whereas in a cross-build
it would be considered an installable build.
In both cases though, the rpath of installed binaries would point to
the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the
qtbase build dir).
This is quite confusing behavior, in more than one way.
Change the build system to consider that an explicit -extprefix should
cause Qt to always be installed, even if -developer-build is
specified.
This means the installed rpaths and on-device install prefix
(CMAKE_INSTALL_PREFIX) will now use the default computed install
prefix, e.g. /usr/local/Qt
It also means that to get a non-installable developer + custom staging
and install (on-device) prefix build, users will have to be explicit
and set all the options
-extprefix ~/qt/qtbase_build_dir
-prefix /usr
-developer-build
Pick-to: 6.2 6.3
Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we get:
Styles ................................. Basic Fusion Imagine iOS
Material Universal macOS Windows
-- Qt is now configured for building. Just run 'cmake --build .
--parallel'
Pick-to: 6.2 6.3
Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and properly find and link against `libatomic` using find_library.
This fixes the qtdeclarative build on the RISC-V platform.
Initial-patch-by: Sprite <SpriteOvO@gmail.com>
Pick-to: 6.2
Pick-to: 6.3
Task-number: QTBUG-99234
Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
We need to add specialHTMLTargets to EXPORTED_RUNTIME_METHODS in order
to use it, as Emscripten does not export it.
Also, EM_ASM is not allowed for SIDE_MODULES, so it's better to use
emscripten::val methods.
Change-Id: I9b352ac98e2a961157f5bb36456bec3e35891270
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This adds significant run-time overhead and should not be on by default.
Pick-to: 6.3
Change-Id: I33d312e31bd714f696d8acf2066eb4b285ff04af
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
When generating .pc files there is a warning when executing
QtFinishPkgConfigFile.cmake:
Ignoring empty string ("") provided on the command line.
This happens because the 'postfix' argument is a part of the script
command line even if it's empty. It also makes no sense to check if
'postfix' is empty using genex, use configuring-time check instead.
Pick-to: 6.2 6.3
Change-Id: If52d9634f4885caefb828976b3c99592a6db3d3c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When PCRE2 is compiled using cmake, a pcre2 cmake file is installed
and Qt fails to configure because components isn't specified for
find_package.
In recent PCRE2 releases components needs to be specified for
find_package.
Fixes: QTBUG-102358
Pick-to: 6.2 6.3
Change-Id: Ib842b2c4b1c0bf38aa5da5475eaa2b3c56c6b822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Raise the CMake log level to STATUS when the 'verbose' argument is
passed to the configure script.
Change-Id: I736d95ab66b115f8416eec7f9e2ee96d1580c78d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- Currently we manually unpack all platform libraries,
that are required for GUI apps, and pack it into single eglmegapack.a library.
It could be better do not execute such additional step,
but have possibility to add required graphical libs
to cmake interface lib via toolchain file list variable.
Pick-to: 6.2 6.3
Change-Id: Ic4122600f02e6828d528ee4f00075f8c27f42e38
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Originally, QT_INTERNAL_EXAMPLES_INSTALL_PREFIX was added to
control the installation of examples when they are built as
ExternalProjects, and was not considered for the non-EP case because
we hoped to switch entirely to EP-based building.
Due to some unsolved issues regarding using EP builds in CI, add the
ability to control the installation of non-EP examples.
This will be used in the CI to allow removing the hacky
INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR assignments in example
projects.
It is also likely that we will not deprecate the non-EP based
building, because it is useful for IDE integration (EP targets
are not as developer-friendly to work with in an IDE in regards
to rebuilding).
Amends 98c89c8cc1
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I02264aaa1daa2c80bb9ef3d02b1831b4ca5d2b84
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the
variable only affects the location of where examples
are installed.
And make sure the paths are passed as CMake paths.
Amends 1031fa1547
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ib92c55488b736d980da2bd88255de78e183de824
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
By default when building ExternalProjects, even if the main ninja
invocation has -v passed, that won't be passed to the nested ninja
calls.
When building examples in the CI, we want to see the full command line
invocations.
Allow passing -v to the nested EP ninja calls by configuring Qt with
-DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI.
We don't want to add -v by default because if the main ninja does not
have one, the nested calls will still be verbose.
Pick-to: 6.2 6.3
Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
So we can see the command line invocations of the built cmake
auto tests.
To achieve that, we create a ninja shell script wrapper, because
ctest --build-and-test does not currently allow specifying custom
build tool options.
Details at
https://gitlab.kitware.com/cmake/cmake/-/issues/22443
Pick-to: 6.2 6.3
Change-Id: I7fb3b7f7f802943a7013c859b2cf39842a34e2e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Read the ANDROID_<SDK|NDK>_ROOT environment variables in qt toolchain
file and use them to chainload the android toolchain file.
Pick-to: 6.2 6.3
Change-Id: I1940ffbaa557974fc26005f4d051030f2cc5c7e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a python script that allows us to run wasm tests in CI, along with
the necessary cmake logic to install the script and execute tests
accordingly.
Change-Id: I93b95c115538c4e27b2b833405acab8162be2a8a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Fix binary_for_strip project not being found when the following
conditions were met:
- building a repo other than qtbase
- qtbase sources are not available on the machine
(usually happens in CI where only the current repo sources are
available).
The issue was that QT_CMAKE_DIR would always be defined, regardless of
which repo was being built and the system would incorrectly assume
the location of the project files.
The fix is to always pick up the sources from qtbase's source dir if
they are available (this time done with an appropriate check),
otherwise use the installed files.
Note that the behavior of always using the qtbase sources if available
is not exactly the best, but it is a more general issue that affects
other code too.
In the name of consistency, make it so for the binary_for_strip
project as well, but add TODOs in code to address the situation
in a separate change.
Amends 39f657032b
Pick-to: 6.2 6.3
Fixes: QTBUG-102064
Task-number: QTBUG-88090
Task-number: QTBUG-101653
Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Using INSTALL_LIBDIR is the only reliable way to get the library install directory.
Amends: d1c56073b4
Pick-to: 6.2 6.3
Change-Id: Ib8c4fb8b4d339c63209393d7fdb3d1c3425b03a4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CROSSCOMPILING_EMULATOR is a target property, not a test property.
Fixes: QTBUG-87864
Pick-to: 6.2 6.3
Change-Id: Icb07e9ed71a6bcbfceb7aa2116bf56eaa0a545c6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option completely ruins the output when running test, as it logs
every single safe heap operation. I don't think this detailed logging
is necessary or reasonable in a normal debug build.
Pick-to: 6.3
Change-Id: I4bb740299d631d21453f9b4a8959634801fb3a1e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink"
section in binaries, a section that is needed for the separate debug
information feature.
binutils version 2.34 mentions the feature for the first time:
https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip
To ensure the debuglink section is preserved, generate a shell wrapper
that calls the original strip binary with an extra option to keep the
required section.
To determine if the option is supported, we build a real shared library
on which strip will be called with the --keep-section option.
If the option is not supported, a wrapper is not generated and the
stock strip binary is used.
This logic only applies when targeting Linux and MinGW + a shared
library Qt. For other targets, the stock strip binary is used.
Developers can opt out of this logic by passing
-DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo.
Pick-to: 6.2 6.3
Fixes: QTBUG-101653
Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
So we can see the exact moc invocations when debugging issues in the
CI.
For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the output
with AUTOGEN output.
Pick-to: 6.2 6.3
Change-Id: I6468ab0e461b3be283e2428e3515cae4d5986242
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Since e2a0ddbb69 , if Qt is configured
as a non-developer-build, some of the CMake tests that include QtSetup
would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE
value.
Make sure that tests always have a DEBUG level, so that if they fail
in the CI, we have more info on what goes wrong.
For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the
output a non default log level.
Amends e2a0ddbb69
Pick-to: 6.2 6.3
Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
