Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
qt6: don't treat absolute paths without known suffix as library
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](qt/qtbase@ea0f00d) 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](qt/qtbase@ea0f00d), 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](qt/qtbase@ea0f00d). 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.
- Loading branch information
