[Interest] Creating fat binaries for Qt6 on macOS

[Dirk Hohndel]

Hi Thiago,

Thanks for the detailed response.

> On Apr 11, 2022, at 13:43, Thiago wrote:
> 
> 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.

I will look into this. I'm thinking that this is a result of this being fat binaries with identical
rpath in both sides.

>> 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.

So... hear me out here... if Qt can switch to OpenGL... and if this thingy doesn't work
unless it's OpenGL... shouldn't Qt simply switch to OpenGL?
Or is this too radically useful?

>> 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.

I have the plugin in my plugin path.
The error went away after I forced an explicit link against this framework.
Makes no sense to me, TBH

>> 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.

That's what I thought as well. The debugging output was extremely useless.
And thanks to macOS being infallible, we of course have no decent 'stroke' 
replacement anymore, so that felt hard as well.

> 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.

Yes, I'll do that... that requires undoing my "hack" to make things work, though.
I'm not sure my brain is fresh enough right now to work on that and create  useful
information. 4+ hours of diving make you tired...

> 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.

I don't think that's it: 

% lipo -info ../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/*.dylib 
Architectures in the fat file: ../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/libworkerscriptplugin.dylib are: x86_64 arm64 

We may need that extra debug info :)

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220411/b1057c2b/attachment.htm>