[Interest] Creating fat binaries for Qt6 on macOS

[Dirk Hohndel]

> On Apr 12, 2022, at 06:20, Thiago wrote:
> 
> 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.

That's exactly what it does. I'm surprised that no one else ran into this, though.
After all, the Qt distribution binaries are all fat binaries.

Here's an example:

% otool -l Subsurface.app/Contents/MacOS/Subsurface | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 48
         path /Users/hohndel/src/install-root/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path @executable_path (offset 12)
--
          cmd LC_RPATH
      cmdsize 128
         path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path /Users/hohndel/src/install-root/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 48
         path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path @executable_path (offset 12)
--
          cmd LC_RPATH
      cmdsize 128
         path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin (offset 12)
> 
>> 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.

:-)

So instead of defaulting to something that works, Qt defaults to something that
may have some vague advantage that you aren't certain about.

Solid reasoning. 🤣


I'll keep playing with the rest and send updates once I have more time figuring out
the details.

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