summaryrefslogtreecommitdiffstats
path: root/cmake/QtFinishPrlFile.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix prl files not to contain hard-coded library pathsAlexandru Croitor2022-06-251-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | Make sure to convert absolute paths generated using the $<TARGET_LINKER_FILE> generator expressions into relative paths. Because prl files are generated for both modules and plugins, we need to pass both a list of qt module locations and qt plugin locations to QtFinishPrl.cmake, and then try to make the absolute path relative to each passed directory. A warning assertion is shown if we no relative path could be made, which will cause an absolute path to be embedded. This should not happen though. Amends f4e998125981038e5e50dab8cc56039faaa0b750 Fixes: QTBUG-104396 Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 754512a64dffa20165e5b08b77e34b82c072f7f8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix static library link order when using qmakeAlexandru Croitor2022-05-121-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 4ab54320817ebbb465af343514d21139a654aed3 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>
* Fix generated pri and prl filesLi Xinwei2021-07-171-0/+1
| | | | | | | | | | | | | | | Quote the paths after "-L". Get MSVC’s implicit link directories from $ENV{LIB}. Fix some issues cause by Inconsistent case. Amends 2c49f85380d7ad79d9473e0f42e7afaa36d31af9 Fixes: QTBUG-95198 Pick-to: 6.2 6.1 Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move resource object files to the beginning of linker line in .prl filesAlexey Edelev2021-06-031-1/+1
| | | | | | | | | Move collected resource objects to the beginning of the linker line to prevent order-related issues. Fixes: QTBUG-92250 Change-Id: Ia046f2820feb693bfadc2b60e07fa001638d4d7b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated prl and pri files for MSVCLi Xinwei2021-06-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Update the comment in QtFinishPrlFile.cmakeJoerg Bornemann2021-05-031-2/+4
| | | | | | | | Clarify that OUT_FILE is not the final .prl anymore and where we get the path of the final .prl from. Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generation of prl files for non-qtbase modulesAlexandru Croitor2020-10-291-5/+17
| | | | | | | | | | | | | | | | | | | Previously we determined if a library represented by an absolute path is a Qt module by checking if it's located in the build dir of the current repo. That is not sufficient for non-qtbase prefix builds, where a Qt module might link against both a module in the current build dir and in the prefix dir. Detect such cases, and rewrite the absolute paths to relocatable paths (either framework flags or paths starting with $$[QT_INSTALL_LIBS]. This should fix building examples with qmake that use QtQuick. Fixes: QTBUG-87840 Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Do not prepend -l to libs starting with dash in prl filesJoerg Bornemann2020-10-221-1/+1
| | | | | | | | For example, we must not prepend -l to -pthread, -framework and -lfoo. Fixes: QTBUG-87760 Change-Id: Ie1bc7a76183c2c4980c519b5f23dde6c47ec85a9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated content of prl files (again)Alexandru Croitor2020-07-311-15/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix building debug apps with qmake on WindowsAlexandru Croitor2020-07-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our CMake build system only generated working .prl files for the Release configuration in debug_and_release. This caused a linking failure when building a Widgets example that links against qtmain, specifically qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external symbol __imp_CommandLineToArgvW referenced in function WinMain The symbol is located in shell32.dll, which was not linked in, because there was no qtmaind.prl file. The fix to generate per config prl files is a bit complicated, because add_custom_command does not support generator expressions in OUTPUT and DEPENDS. Instead we pre-generate 2 files per config, one with the preliminary prl file content and another file that contains the final prl file path (via generator expression). Then we iterate over all configurations and create custom commands with well known paths, and the final prl file is created by the script called by the command. Amends 06557312d2a030f9ff771488bd6c97690a125a3d Task-number: QTBUG-85240 Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Write object libs of Qt resources to .prl filesJoerg Bornemann2020-06-161-1/+6
| | | | | | | | | | | | | | | Since commit e343affd634 we're creating object libraries for Qt resources in static libraries. Those must be reflected in the generated .prl files for static builds of Qt. In qt_add_resource, we now calculate the install locations of the object files of rcc-generated C++ files and save them in the target property QT_RCC_OBJECTS. This property is then passed to QtFinishPrlFile to write the object file paths to the .prl file. Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Do not use $$[QT_INSTALL_LIBS/get] in generated .prl filesJoerg Bornemann2020-06-161-2/+2
| | | | | | | | | We do not support building with qmake from the build directory in prefix builds. Therefore we can just use the standard QT_INSTALL_LIBS property instead of the /get variant. Change-Id: I82ccaf1894fb1dccc9ec18b4984b582b555ce0f8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix qmake mixing for framework buildsAlexandru Croitor2020-06-041-1/+1
| | | | | | | | | | | | | Include headers in .pri files should point to the framework Headers dirs. The module name in the .pri file is not versioned when it's a bundle. Paths to system frameworks in .prl files should instead be replaced with -framework Foo flags. Change-Id: Ia353d033799fae40a1bc55fad6f86b2c8ef76c56 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Generate qmake .prl filesJoerg Bornemann2020-04-171-0/+57
This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 16:14:59 +0000