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 bc88bb34caf1185a25eda77ee022843c0ca988b0. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: Idce69db0cf79d3e32916750bfa61774ced977a7e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>