From 3dec620618fe89b84849a01503ee1a3dac73dae7 Mon Sep 17 00:00:00 2001 From: Peter Kling <1018801+pitkling@users.noreply.github.com> Date: Sat, 21 Dec 2024 21:22:52 +0100 Subject: [PATCH] qt6: don't treat absolute paths without known suffix as library MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes issue #366069 (broken sioyek darwin build) by adapting an upstream change when Qt was updated from 6.7.2 to 6.7.3 in PR #344928. MIght fix other similar issues (e.g., for packages depending on `qt6.qtspeech`). Not sure whether this just shadows a deeper underlying problem (already present before). # Details (Note: Take the following with a grain of salt, as I've not much experience with cmake/qmake/Qt.) [This upstream commit](https://github.com/qt/qtbase/commit/ea0f00d5d47db9ac242c914dd479bebf6737f22b) changed how Qt treats linker flags without a suffix (like `.so`) when generating `.pri`/`.prl` files. Until 6.7.2, a linker flag like `ws2_32` was left untouched. The above commit changed it such that such flags are converted to `-lws2_32` (seemingly in order to better support FFmpeg, according to the commit message). Now, nixpkgs on darwin links some libraries, like `QtMultimedia` via framwork paths like `/nix/store/wmm6s68wk9ygg84ibzdf95yp22lcg4ay-qtmultimedia-6.7.3/lib/QtMultimedia.framework/Versions/A/QtMultimedia`. As long as these are part of the current build dir or of Qt's `$prefix/lib` dir, they [are recognized as frameworks](https://github.com/qt/qtbase/blob/b839e9b36db3a4e50dfb34521d8ef8de1fd01969/cmake/QtFinishPrlFile.cmake#L48-L53) and handled accordingly. This works, e.g., for something like `/nix/store/rdjd1nqlr1ncr4616dcyqdf6ymqy82xc-qtbase-6.7.3/lib/QtGui.framework/Versions/A/QtGui` since it is part of `qt6.qtbase`. However, QtMultimedia is not part of `qt6.qtbase`, so `/nix/store/wmm6s68wk9ygg84ibzdf95yp22lcg4ay-qtmultimedia-6.7.3/lib/QtMultimedia.framework/Versions/A/QtMultimedia` is not recognized as a framework path and, instead, treated like a [non-Qt library](https://github.com/qt/qtbase/blob/b839e9b36db3a4e50dfb34521d8ef8de1fd01969/cmake/QtFinishPrlFile.cmake#L54-L61). Now, before the [above mentioned upstream commit](https://github.com/qt/qtbase/commit/ea0f00d5d47db9ac242c914dd479bebf6737f22b), the linker flag was handed over to `clang++` unchanged. After the upstream commit, it is transformed into `-l/nix/store/wmm6s68wk9ygg84ibzdf95yp22lcg4ay-qtmultimedia-6.7.3/lib/QtMultimedia.framework/Versions/A/QtMultimedia`, which causes a linker error (since it's a directory and not a library). This commit adds a patch that slightly adapts the [upstream commit](https://github.com/qt/qtbase/commit/ea0f00d5d47db9ac242c914dd479bebf6737f22b). Namely, it only prepends flags without a suffix (like `ws2_32`) with an `-l` if they are not given as an absolute path. # Additional Remarks WIth this fix, the generated `prl` files look again exactly as before the update from Qt 6.7.2 to 6.7.3 and linking of packages like sioyek works again. However, I'm not sure whether this is actually the correct way to fix the issue. It seems to me that instead of handing `/nix/store/wmm6s68wk9ygg84ibzdf95yp22lcg4ay-qtmultimedia-6.7.3/lib/QtMultimedia.framework/Versions/A/QtMultimedia` through to `clang++`, it should be converted into `-framework QtMultimedia` (with a suitable `-F …` flag). In fact, somehow these flags do end up in the actual linker command, not sure how though. Also, I am surprised that `clang++` does not choke on getting simply a directory as an argument. --- pkgs/development/libraries/qt-6/default.nix | 1 + ...treat-abspaths-without-suffix-as-libraries.patch | 13 +++++++++++++ 2 files changed, 14 insertions(+) create mode 100644 pkgs/development/libraries/qt-6/patches/0011-qtbase-dont-treat-abspaths-without-suffix-as-libraries.patch diff --git a/pkgs/development/libraries/qt-6/default.nix b/pkgs/development/libraries/qt-6/default.nix index bfa2de2e529abc..ebf1fb494f3b0b 100644 --- a/pkgs/development/libraries/qt-6/default.nix +++ b/pkgs/development/libraries/qt-6/default.nix @@ -75,6 +75,7 @@ let ./patches/0008-qtbase-find-qmlimportscanner-in-macdeployqt-via-envi.patch ./patches/0009-qtbase-check-in-the-QML-folder-of-this-library-does-.patch ./patches/0010-qtbase-derive-plugin-load-path-from-PATH.patch + ./patches/0011-qtbase-dont-treat-abspaths-without-suffix-as-libraries.patch # Backport patch for https://bugs.kde.org/show_bug.cgi?id=493116 # FIXME: remove for 6.8.1 (fetchpatch2 { diff --git a/pkgs/development/libraries/qt-6/patches/0011-qtbase-dont-treat-abspaths-without-suffix-as-libraries.patch b/pkgs/development/libraries/qt-6/patches/0011-qtbase-dont-treat-abspaths-without-suffix-as-libraries.patch new file mode 100644 index 00000000000000..8f87ef5f30f719 --- /dev/null +++ b/pkgs/development/libraries/qt-6/patches/0011-qtbase-dont-treat-abspaths-without-suffix-as-libraries.patch @@ -0,0 +1,13 @@ +diff --git a/cmake/QtGenerateLibHelpers.cmake b/cmake/QtGenerateLibHelpers.cmake +index 96675267d2..c9d4a69497 100644 +--- a/cmake/QtGenerateLibHelpers.cmake ++++ b/cmake/QtGenerateLibHelpers.cmake +@@ -10,7 +10,7 @@ function(qt_get_library_name_without_prefix_and_suffix out_var file_path) + if(NOT file_path MATCHES "^-") # not a linker flag + get_filename_component(basename "${file_path}" NAME_WE) + get_filename_component(ext "${file_path}" EXT) +- if(NOT ext) # seems like a library name without prefix and suffix ++ if(NOT ext AND NOT IS_ABSOLUTE "${file_path}") # seems like a library name without prefix and suffix + set(${out_var} "${file_path}" PARENT_SCOPE) + return() + endif()