366b4d3ae7
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Alexandru Croitor
|
47b879aa0b |
CMake: Place resources into static libraries, not object libraries
Take 2.
Re-land previously reverted commit, due to not handling resource names
that are not valid c++ identifiers. Now we sanitize the resource names
just like rcc does by replacing non-alphanumeric characters with
underscores.
Original commit message.
During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was
decided to keep resources in an object file (object library), rather
than putting them directly into a static library when doing a static
Qt build, so that the build system can take care of linking the
object file directly into the executable and thus not forcing
project developers to manually initialize resources with
the Q_INIT_RESOURCE() macro in project code.
This worked for most qmake and cmake projects, but it created
difficulties for other build systems, in the sense that these projects
would have to manually link to the resource object files, otherwise
they would get link time errors about undefined resource symbols,
assuming they kept the Q_INIT_RESOURCE() calls.
If the project code didn't contain Q_INIT_RESOURCE calls, the
situation would be even worse, the linker would not error out,
and the missing resources would only be discovered at runtime.
It's also an issue in CMake projects that try to link to the
library files directly instead of using the library target names,
which means the object files would not be automatically linked in.
Many projects try to do that because we don't yet offer a convenient
way to install libraries and reuse them in other projects (the SDK
case), so projects end up shipping only the libraries, without the
resource object files.
We can improve the situation by moving the resources back into their
associated static libraries, and only keeping a static initializer as
a separate object file / object library, which references the actual
resource initializer symbol, to ensure it does not get discarded
during linking.
This way, projects that link using targets get no behavior difference,
whereas projects linking to static libraries directly can still
successfully build as long as their sources have all the necessary
Q_INIT_RESOURCE calls.
To ensure the resource symbols do not get discarded, we use a few new
private macros. We declare the resource init symbols we want to keep as
extern symbols and then assign the symbol addresses to volatile
variables.
This prevents discarding the symbols with the compilers / linkers we
care about.
It comes at the cost of an additional static initializer per resource,
but we would get the same + a bigger performance hit if we just used
Q_INIT_RESOURCE twice (once in the object lib and once in project
code), which internally needs to traverse a linked list of all
resources to check if a resource was initialized or not.
For GHS / Integrity, we also need to use a GHS-specific pragma to keep
the symbols, which we currently use in qtdeclarative to ensure qml
plugin symbols are not discarded.
The same macros will be used in a qtdeclarative change to prevent
discarding of resources when linking to static qml plugins.
A cmake-based test case is added to verify that linking to static
libraries directly, without linking to the resource initializer
object libraries, works fine as long as the project code calls
Q_INIT_RESOURCE for the relevant resource.
This reverts commit
|
||
|
Alexandru Croitor
|
bc88bb34ca |
Revert "CMake: Place resources into static libraries, not object libraries"
This reverts commit
|
||
|
Alexandru Croitor
|
ce8874fc3b |
CMake: Place resources into static libraries, not object libraries
During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was decided to keep resources in an object file (object library), rather than putting them directly into a static library when doing a static Qt build, so that the build system can take care of linking the object file directly into the executable and thus not forcing project developers to manually initialize resources with the Q_INIT_RESOURCE() macro in project code. This worked for most qmake and cmake projects, but it created difficulties for other build systems, in the sense that these projects would have to manually link to the resource object files, otherwise they would get link time errors about undefined resource symbols, assuming they kept the Q_INIT_RESOURCE() calls. If the project code didn't contain Q_INIT_RESOURCE calls, the situation would be even worse, the linker would not error out, and the missing resources would only be discovered at runtime. It's also an issue in CMake projects that try to link to the library files directly instead of using the library target names, which means the object files would not be automatically linked in. Many projects try to do that because we don't yet offer a convenient way to install libraries and reuse them in other projects (the SDK case), so projects end up shipping only the libraries, without the resource object files. We can improve the situation by moving the resources back into their associated static libraries, and only keeping a static initializer as a separate object file / object library, which references the actual resource initializer symbol, to ensure it does not get discarded during linking. This way, projects that link using targets get no behavior difference, whereas projects linking to static libraries directly can still successfully build as long as their sources have all the necessary Q_INIT_RESOURCE calls. To ensure the resource symbols do not get discarded, we use a few new private macros. We declare the resource init symbols we want to keep as extern symbols and then assign the symbol addresses to volatile variables. This prevents discarding the symbols with the compilers / linkers we care about. It comes at the cost of an additional static initializer per resource, but we would get the same + a bigger performance hit if we just used Q_INIT_RESOURCE twice (once in the object lib and once in project code), which internally needs to traverse a linked list of all resources to check if a resource was initialized or not. For GHS / Integrity, we also need to use a GHS-specific pragma to keep the symbols, which we currently use in qtdeclarative to ensure qml plugin symbols are not discarded. The same macros will be used in a qtdeclarative change to prevent discarding of resources when linking to static qml plugins. A cmake-based test case is added to verify that linking to static libraries directly, without linking to the resource initializer object libraries, works fine as long as the project code calls Q_INIT_RESOURCE for the relevant resource. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: I39c325aac91e36d53c3576a39f881949c3b21e3f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> |