qt5: Output of macdeployqt not working after update to 5.15.10_1

[ubruhin]

brew gist-logs <formula> link OR brew config AND brew doctor output

% brew config
HOMEBREW_VERSION: 4.1.7
ORIGIN: https://github.com/Homebrew/brew
HEAD: d4444b563e24ac7c05a93121c464c02dfa04d44f
Last commit: 3 days ago
Core tap JSON: 30 Aug 21:02 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 4
Homebrew Ruby: 2.6.10 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.10_1/bin/ruby
CPU: quad-core 64-bit penryn
Clang: 13.0.0 build 1300
Git: 2.41.0 => /usr/local/bin/git
Curl: 7.87.0 => /usr/bin/curl
macOS: 11.7.6-x86_64
CLT: 13.2.0.0.1.1638488800
Xcode: N/A

% brew doctor
Your system is ready to brew.

Verification

• My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

I want to build an application with Qt, create a bundle with macdeployqt and run the bundled application. See exact steps below.

Note that this worked fine until Qt 5.15.10, but it stopped working with Qt5.15.10_1 which was released 2 days ago. For verification, I run the steps below on a system which still had Qt 5.15.10 installed, and it worked fine. Then I updated Qt, tried it again and the error occurs.

This issue breaks CI of LibrePCB. CI worked fine 2 days ago (logs). Since yesterday, it fails with the mentioned error (logs). I saw that commit 9b99c9a was added just in between these two CI runs so it might be related to this problem.

I guess macdeployqt does not work properly (it now runs much faster than normal) but I don't know if the problem is located within macdeployqt or somewhere else.

What happened (include all command output)?

After building a Qt application bundle (see steps below), the application doesn't work but just prints this error to the console:

qt.qpa.plugin: Could not load the Qt platform plugin "cocoa" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: cocoa.

zsh: abort      ./test.app/Contents/MacOS/test

What did you expect to happen?

The application bundle should start and a graphical message box must appear.

Step-by-step reproduction instructions (by running brew commands)

# CMakeLists.txt

cmake_minimum_required(VERSION 3.5)
project(test LANGUAGES CXX)
find_package(Qt5 COMPONENTS Gui Widgets REQUIRED)
add_executable(test MACOSX_BUNDLE main.cpp)
target_link_libraries(test PUBLIC Qt5::Core Qt5::Gui Qt5::Widgets)

// main.cpp

#include <QtWidgets>
#include <QtCore>

int main(int argc, char* argv[]) {
  QApplication app(argc, argv);
  QMessageBox::information(0, "Test", "Works!");
  return 0;
}

brew install qt@5 cmake
brew link qt@5
export CMAKE_PREFIX_PATH=/usr/local/opt/qt5/lib/cmake
cmake .
make
macdeployqt test.app -dmg -always-overwrite
./test.app/Contents/MacOS/test # run application

[SMillerDev]

macdeployqt isn't part of brew though so it's very hard for us to tell why that one doesn't work. Please also file an issue with the devs of that.

[ubruhin]

Well, I'm not convinced that the issue is coming from Qt itself. The Qt sources download link in [email protected] was not changed since 2 months so I assume it still downloads the same Qt 5.15.10 sources which worked fine the last two months. But then a new brew package (with "_1" version suffix) appeared and it stopped working.

But I don't understand what commit 9b99c9a actually did. I don't know what checksums these are and what the removed rebuild 1 did. Maybe this commit is related to the problem, maybe not. I'm not familiar with Homebrew so my hope is that someone could take a look at this to find out where the issue seems to be located (Homebrew or Qt or even something else). I don't want to spam the Qt bugtracker as long as there is absolutely no evidence that the issue is coming from Qt.

[cho-m]

I believe this is a side effect of RPATH modifications (enabled for all formulae since 83ef417).

I tried your reproduction and see lldb complain about loading dylibs, which I can confirm point to incorrect path. I think the rewritten @loader_path for external libs (e.g. libpng) is not expected by Qt5 and macdeployqt doesn't copy/rewrite them inside app bundle.

❯ otool -L ./test.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui | rg 'QtGui|@loader_path'
./test.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui:
	@executable_path/../Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.15.0, current version 5.15.10)
	@loader_path/../../../QtCore.framework/Versions/5/QtCore (compatibility version 5.15.0, current version 5.15.10)
	@loader_path/../../../../../../../opt/libpng/lib/libpng16.16.dylib (compatibility version 57.0.0, current version 57.0.0)

Haven't checked if there is a workaround. Bit curious if this also impacts CMake's fixup_bundle or if they do something different.

---

CC @carlocab who may be more familiar with state of RPATH rewrites in brew.

---

EDIT:

But I don't understand what commit 9b99c9a actually did.

You need to look at previous commit(s) (e.g. c64da2d) as the linked commit is just distribution of new binaries.

The change was to fix bundled Chromium's FFmpeg build with binutils. Should be for QtWebEngine which I don't think you are using?

[ubruhin]

I believe this is a side effect of RPATH modifications (enabled for all formulae since 83ef417).

Ahh, that sounds plausible!

Bit curious if this also impacts CMake's fixup_bundle or if they do something different.

I'm not familiar with fixup_bundle but I suspect in my case it cannot be used as an alternative to macdeployqt because macdeployqt does more than just rewritings dylib paths. For example it also allows to bundle the referenced QML modules which is of course specific to Qt.

Should be for QtWebEngine which I don't think you are using?

Correct, I don't use QtWebEngine. But I use QML 🙂

Just to confirm, there's no way to get the old (working) Qt5 binaries installed with brew (in an automated, headless way), right? The CI of LibrePCB is currently broken due to this issue and I have no idea yet how to get it running again. As the issue seems to be non-trivial, I suspect it could take quite some time until there's a solution for it.

[cho-m]

Just to confirm, there's no way to get the old (working) Qt5 binaries installed with brew (in an automated, headless way), right?

Not easily. Don't know if there is a workaround via API mode but some users occasionally use Git/Tap mode (HOMEBREW_NO_INSTALL_FROM_API) and checkout older git commit as workaround. This does lock in some older versions of formulae from that commit.

Homebrew could try a rebottle of qt@5 if others agree to it as that currently doesn't rewrite RPATHs.

---

Responding to my own comment

Bit curious if this also impacts CMake's fixup_bundle or if they do something different.

I think this broke fixup_bundle based on wxmaxima failure in #139981, e.g.

  -- fixup_bundle
  --   app='/tmp/wxmaxima-20230820-24435-14myu5f/wxmaxima-Version-23.08.0/build-wxm/src/wxmaxima.app'
  --   libs=''
  --   dirs=''
  --   ignoreItems=''
  -- fixup_bundle: preparing...
  -- warning: embedded item does not exist '/opt/opt/libpng/lib/libpng16.16.dylib'
  -- 
  warning: cannot resolve item '@loader_path/../../../../opt/libpng/lib/libpng16.16.dylib'
  
    possible problems:
      need more directories?
      need to use InstallRequiredSystemLibraries?
      run in install tree instead of build tree?

[hluk]

I think I see an error also related this with cmake/cpack (run using GitHub Actions):

+ cpack
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: copyq
CPack: - Install project: copyq []
CMake Error at /usr/local/Cellar/cmake/3.27.4/share/cmake/Modules/BundleUtilities.cmake:458 (message):
  otool -l failed: 1

  error:
  /Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool-classic:
  can't open file:
  @loader_path/../../../../../opt/freetype/lib/libfreetype.6.dylib (No such
  file or directory)

Unfortunately, I could not find a workaround (hluk/CopyQ#2450).

[ZhongRuoyu]

See also: https://github.com/orgs/Homebrew/discussions/4735

[stefangpeter]

I can confirm the problem. Since 28th the requested depedencies of some of the qt libs in the app bundle are just plain missing in the app bundle (libpng etc).

[manongjohn]

I've also been dealing with build issues due to recent changes in macdeployqt when building in Big Sur environment.

When it deploys stuff to Contents/Frameworks

1. The framework dependency paths has lib instead of Frameworks. Example: @loader_path/../../lib/QtCore.framework/Versions/5/QtCore instead of the expected @loader_path/../../Frameworks/QtCore.framework/Versions/5/QtCore
2. Doesn't deploy all the Qt*.frameworks despite the dylibs being deployed. It wasn't deploying the following frameworks for me: QtDBus, QtPdf, QtQml, QtQmlModels, QtQuick, QtVirtualKeyboard

[cho-m]

Rebottled qt@5 (#141242) and its dependencies glib (#141248) & freetype (#141250).

It may take some extra time for these to be available via API. Once available, you can try updating and reinstalling locally, e.g. brew update && brew reinstall qt@5 glib freetype.

Let us know if any other issues for qt@5 usage.

Note this may not fix usage with other Qt5 modules, Qt6 usage, or CMake usage that links to formulae that are still using modified RPATHs. Each formula will need to be rebottled individually.

[ubruhin]

Awesome, thank you very much! 👍

So far, everything looks good for me. The LibrePCB CI is now successful again and the resulting *.dmg seems to run as expected.

Note this may not fix usage with other Qt5 modules, Qt6 usage, or CMake usage that links to formulae that are still using modified RPATHs. Each formula will need to be rebottled individually.

Hm I'm not sure if I understand correctly, somehow it sounds like the solution is not really generic and may still lead to troubles. But for example the library opencascade which LibrePCB depends on (beside Qt) seems to be bundled fine 🤔

[cho-m]

Going to close this as resolved for main issue (qt@5 usage). Checked qt@5 dependency tree and there shouldn't be any issues there.

Qt6 is still impacted so can try to rebottle qt or wait for #137047 to handle this with a new release.

[hluk]

Thanks for the fix. 🙏

Unfortunately, I still have a problem when using cpack (https://github.com/hluk/CopyQ/actions/runs/6039477239/job/16449187277) - now it complains about a different library (libsharpyuv - not sure where it comes from):

 + cpack
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: copyq
CPack: - Install project: copyq []
CMake Error at /usr/local/Cellar/cmake/3.27.4/share/cmake/Modules/BundleUtilities.cmake:458 (message):
  otool -l failed: 1

  error:
  /Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool-classic:
  can't open file: @rpath/libsharpyuv.0.dylib (No such file or directory)

[ubruhin]

Ah I now quickly compared the contents of an older LibrePCB bundle with the current one and I can confirm that two libraries are no longer contained in the bundle:

• libsharpyuv.dylib
• libpcre2-8.0.dylib

But I don't know if they should be contained in the bundle. At least in my case I didn't experience any runtime issue with the bundle.

[hluk]

I managed to bundle my app using macdeployqt instead of cpack without any apparent problems (https://github.com/hluk/CopyQ/actions/runs/6065215399/job/16454474022).