[Interest] Creating fat binaries for Qt6 on macOS

[Thiago Macieira]

On Monday, 11 April 2022 23:17:17 PDT Dirk Hohndel wrote:
> > 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.

It's possible. The tool is parsing the output of otool -l, so if that prints 
the rpaths for both members of the fat binary, it would indeed get confused.

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

My guess is that it has to be explicit on your side because Metal has some 
advantage that OpenGL doesn't. I wouldn't know what, since it's not an area I 
pay attention to.

> 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/*.dyli
> b Architectures in the fat file:
> ../../build/Subsurface.app/Contents/Resources/qml/QtQml/WorkerScript/libwor
> kerscriptplugin.dylib are: x86_64 arm64
> 
> We may need that extra debug info :)

I meant the QMachOParser content. I wrote that in 2013 to make it really fast 
to scan files to find out if they are plugins. Before that, Qt opened each 
file and did a full string search, which was slow in debug builds because of 
all the debug info in those files. The code does deal with fat binaries and 
was tested against them.... but by that time, PowerPC and even 32-bit x86 were 
no longer relevant for macOS. There could be latent bugs.

The ELF parser is much older, from before the Qt public history.

The COFF-PE parser for Windows is new in 6.3.

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