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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
