[Interest] Creating fat binaries for Qt6 on macOS

[Thiago Macieira]

Hello Dirk.

On Sunday, 10 April 2022 10:22:21 PDT Dirk Hohndel wrote:
> ERROR: "error:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
> ain/usr/bin/install_name_tool: \"-delete_rpath
> /Users/hohndel/src/install-root/lib\" specified more than once\nUsage:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
> ain/usr/bin/install_name_tool [-change old new] ... [-rpath old new] ...
> [-add_rpath new] ... [-delete_rpath old] ... [-id name] input\n"

This one looks like a legitimate bug. The code doing the looping that adds 
-delete_rpath has been there since 2014 and the man page for it says:

       -delete_rpath old
              deletes  the  rpath path name old in the specified Mach-O 
              binary.  More than one of these options can be specified. [...]

The error message is talking about how the same path was being removed more 
than once, which means your binary has it twice. I guess this had simply never 
occurred in the past. Deduplicating the paths is not a bad idea in 
macdeployqt, but you can also investigate why your build arrived at this point 
with twice the same rpath and change that.

> QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi()
> to override the default.

> That first error is weird... I thought Qt on macOS was using OpenGL..

No, it now uses Metal. Because Apple likes to deprecate perfectly good APIs 
and replace with something new. We don't do that on Linux (*cough* PipeWire 
*cough*)...

https://doc.qt.io/qt-6/quick-changes-qt6.html#changes-to-qquickwidget
"QQuickWidget is functional only when the scenegraph is rendering with OpenGL. 
It will not be functional when using another graphics API, such as Vulkan or 
Metal. Applications relying on QQuickWidget should force the usage of OpenGL 
by calling QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL) in their 
main() function."

I don't know why the default has changed or why Metal is better. Maybe someone 
else can chime in.

> And that second one is why I'm mainly writing this message... because
> QtQml.WorkerScript is there. macdeployqt doesn't copy it (I'll need to
> figure out how to write a bug report for that one), but I manually copy it
> in place:
> 
> % ls -l ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework

That's the framework. There must be a plugin somewhere.

> Any idea what I may be doing wrong? This appears to work if I only build an
> arm64 binary. But I get the error above for a fat binary. All the libraries
> and plugins that I can find are indeed fat, e.g.:
> 
> % lipo -info
> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke
> rScript Architectures in the fat file:
> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke
> rScript are: x86_64 arm64
> 
> Any pointers welcome :)

Probably a failure to load the plugin, for one of two reasons: either 
QPluginLoader concluded the file in question isn't a valid plugin, or it did 
but dlopen() subsequently failed.

Can you run with QT_DEBUG_PLUGINS=1 set in your environment and see if it logs 
a reason why? Unlike the new COFF-PE parser and the rewritten ELF parser, I 
didn't add extra debugging to the Mach-O parser itself in 2013. But it should 
accurately report at the end why it doesn't think a given .dylib isn't a 
plugin.

As you said it works if you build thin binaries, either there's something that 
remained thin and you're missing it, or most likely there's a failure in that 
parser trying to find the plugin metadata. If that's the case, please create a 
bug report and attach the plugin's .dylib, and I'll find out where it went 
wrong. I might then even add that extra debugging that the other two file 
formats have.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering