Packaging for Mac: macOS's tar seems to mess up binaries?!

l3u_

Hi all,

I provide a Mac App package for one of my projects (although I'm really not a Mac user …). Currently, I build on macOS 10.14 "Mojave", using a static build of Qt 5.15.16 and qmake. This yields an .app folder I create a .tar.xz archive from (to get better compression). This seemed to work fine for the last few years.

However, I now played around with Qt 6 (Qt 5 won't be around forever ;-). Using macOS 12.7.4 "Monterey", I could could build a static version of Qt 6.7.3, as well as my project. But after unpacking the xz tarball my release script creates, I could not start the program: The icon was overlayed with some "stop" sign and when starting it, I get an error saying "This program can't be started because it is not supported on this Mac" or such.

I first thought this must be due to my Qt 6 build, but apparently, it's tar:

I can run the built app folder without a problem. But as soon as it's tared (no matter if it's compressed using xz or not), the binary is altered after it's unpacked again:

Here's the original app folder's binary:

% ls -l
total 29856
-rwxr-xr-x  1 tobias  staff  21822704 19 Nov 22:29 Muckturnier

% file Muckturnier
Muckturnier: Mach-O 64-bit executable x86_64

% md5 Muckturnier
MD5 (Muckturnier) = 8883bfcd40d39d5b3459490dfe720be9

And this is what comes out when a tarball is created from the app folder and it's unpacked again:

% ls -l
total 29856
-rwxr-xr-x  1 tobias  staff  21822704 19 Nov 22:29 Muckturnier

% file Muckturnier
Muckturnier: data

% md5 Muckturnier
MD5 (Muckturnier) = f57e510f88bce9d1fed0e0295104fea7

The byte size is still the same, but somehow, the file itself seems to be messed up!

What on earth happens here?! Can somebody with more insight of that Mac stuff give me a hint? Thanks for all help!

l3u_

When I scp the .app folder to my Linux host, create the tarball there and scp it back to macOS, I can unpack and use it …

Does this multi-billion-dollar company really package a broken tar command and doesn't fix it?!

IgKh

@l3u_ said in Packaging for Mac: macOS's tar seems to mess up binaries?!:

Does this multi-billion-dollar company really package a broken tar command and doesn't fix it?!

Sounds about right. Get GNU tar from homebrew and package with that.

l3u_

Homebrew … okay, I'll have to check that out. I really know nothing about that Mac stuff ;-) Thanks for the info!

SGaist

Hi,

Taking aside the tar issue, macOS rather uses dmg files for distribution. Qt provides macdeployqt which builds such things and that could simplify your life a bit.

l3u_

Yeah I know … however, AFAIK before macOS 10.15 "Catalina", decent compression (LZMA) for DMG images wasn't available.

The oldest version I could use to build Qt 5 back then was macOS 10.14 "Mojave", which would only create ZIP compressed DMG files that were way bigger than a tar.xz archive. However, I could unpack such an archive there by simply double clicking on it … I thus thought it would be okay to save space on my server, backups etc. and of course traffic by using tar.xz.

With macOS 12.7.4 "Monterey", I can pack my stuff using

hdiutil create -format ULMO -srcfolder some_folder project-xyz.dmg

The result is still a bit larger than the same data compressed via xz, but it's way better than the old version. However, such a DMG image can't be opened using "Mojave". And I'm not sure if I can expect everybody to have at least "Catalina" – I really have no idea what those Apple folks use ;-)

@SGaist So: Asking the other way round: Could I be relatively sure to reach the majority of Mac users when I create an LZMA compressed DMG image?

l3u_

PS: Thanks for the hint with macdeployqt, but in this case, the packaging is quite easy, as I build using a static Qt. So there's only the binary itself, without having to add external libraries.