[MacPorts] #67672: qt5-qtbase @5.15.8: macdeployqt doesn't fix QtWebEngineProcess (was: qt5 @5.15.8+qt5-qtwebengine: QtWebEngineProcess has dependencies with absolute path)

[MacPorts]

#67672: qt5-qtbase @5.15.8: macdeployqt doesn't fix QtWebEngineProcess
----------------------------------+---------------------------------
  Reporter:  kaamui               |      Owner:  MarcusCalhoun-Lopez
      Type:  defect               |     Status:  assigned
  Priority:  Normal               |  Milestone:
 Component:  ports                |    Version:
Resolution:                       |   Keywords:
      Port:  qt5 qt5-qtwebengine  |
----------------------------------+---------------------------------

Comment (by ryandesign):

 Forgive me for not reading your messages closely enough.

 MacPorts is primarily intended for use on your computer. You install
 MacPorts, install the software you want, it installs the dependencies you
 need, and the software will work on your computer. Such users are expected
 to leave the files (libraries/frameworks/programs) exactly where MacPorts
 put them. Since that's the case, the libraries/frameworks/programs are
 linked in the most straightforward manner: by absolute paths.

 If you want to make an app that contains some libraries/frameworks that
 were compiled by MacPorts and that can be redistributed to users who don't
 have MacPorts installed, the libraries/frameworks you use have to be
 copied inside the app bundle and all of the linkages have to be edited to
 use relative paths based on `@executable_path`, `@loader_path`, or (if you
 only need to support Mac OS X 10.5 or later) `@rpath`. You can do this
 manually for each linkage using Apple's `install_name_tool` or using a
 third-party tool that attempts to automate the process like
 `dylibbundler`. I didn't realize until comment:7 that you were already
 using a different third-party tool, `macdeployqt`, to do this step.

 After rereading your comments, I understand now that the problem here
 isn't that the linkages of your app and the libraries/frameworks weren't
 edited properly (they were); the problem is that the QtWebEngineCore
 framework contains a QtWebEngineProcess app, and this QtWebEngineProcess
 app's linkage hasn't been edited. The stackoverflow post you referred to
 said the same issue was seen when Qt was installed by Homebrew. This
 sounds like a bug in `macdeployqt`. Until it is fixed, you should be able
 to edit QtWebEngineProcess's linkage manually using `install_name_tool`.

 I understand that the official Qt binary distribution doesn't have this
 issue. It is built using `@rpath`. Using `@rpath` causes some problems so
 in MacPorts we've decided not to ship libraries that use `@rpath`. The bug
 may be that `macdeployqt` expects things to be built with `@rpath`.

 Searching the [https://bugreports.qt.io Qt bug tracker] for "macdeployqt"
 I found [https://bugreports.qt.io/browse/QTBUG-84200 bug 84200] which
 seems to describe the problem exactly. They closed it as not their
 problem, referring the user back to Homebrew; I disagree with that
 conclusion.

 I also found [https://bugreports.qt.io/browse/QTBUG-41611 bug 41611] which
 appears to date from a time before Qt used `@rpath` and mentions a
 workaround that could be used at the time. It notes that the workaround
 "won't be necessary once we support using `@rpath`, which should be done
 in Qt 5.5.0." The operative word in that sentence to me is "support". If
 Qt ''supports'' using `@rpath` that's great but as long as they also
 support ''not'' using `@rpath` (as in MacPorts and apparently Homebrew)
 this is a bug in `macdeployqt`. If upstream will not fix that bug, maybe
 we will have to tackle it ourselves.

 Just to close out the `dylibbundler` suggestion, I discovered that
 [https://github.com/auriamg/macdylibbundler/issues/12 dylibbundler doesn't
 support frameworks] so it wouldn't be suitable for use with a Qt app.

 If you are still running Qt 5.15.8 as per the ticket summary, note that
 5.15.10 is available in MacPorts via `sudo port selfupdate` and `sudo port
 upgrade outdated`.

-- 
Ticket URL: <https://trac.macports.org/ticket/67672#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS