Text file merging is broken on Tahoe

[TellowKrinkle]

muniversal relies on libtool failing when given non-macho objects: ​https://github.com/macports/macports-ports/blob/c4b129e884e2592023c601ac57de0cc5283bbf2e/_resources/port1.0/group/muniversal-1.1.tcl#L449

However starting with tahoe, that has been downgraded to a warning:

$ echo 0 > a.txt
$ echo 1 > b.txt
$ /usr/bin/libtool a.txt b.txt -o c.txt
libtool: warning: not a mach-o 'a.txt'
libtool: warning: not a mach-o 'b.txt'
$ file c.txt
c.txt: current ar archive random library

As a result, any port that tries to merge text files (e.g. glib2) ends up with empty ar archives in place of all their merged text files

[ryandesign (Ryan Carsten Schmidt)]

That could explain some other open tickets.

[ryandesign (Ryan Carsten Schmidt)]

Like #73776.

[ryandesign (Ryan Carsten Schmidt)]

Perhaps instead of relying on program exit codes to guess if a file is a Mach-O binary, we should use file (or a simpler built-in check of the file's first bytes) to find out.

[TellowKrinkle]

I'd recommend against file, its output can change between OS releases. The reason macOS 10.13's archive utility can't decompress .tar.xz files is actually because they internally used file to figure out if a file was a .tar.xz, and at some point the capitalization of file's description of .tar.xz files changed and archive utility stopped recognizing them.

[ryandesign (Ryan Carsten Schmidt)]

I would too. I'd think comparing the file's MIME type would have been better than comparing descriptive text, but even MIME types can change. And I'd like to avoid the overhead of running the file executable for each file to be merged.

There's already a very simple file type detection in the muniversal portgroups to identify executable scripts ("test \"`head -c2 ${dir1}/${fl}`\" = '#!'") which could be extended into a slightly more advanced function that could distinguish between script, Mach-O, and other.

Identifying Mach-O is a little more complicated, since there are 5 possible values for the first four bytes:

• 0xFEEDFACE (32-bit big-endian)
• 0xCEFAEDFE (32-bit little-endian)
• 0xFEEDFACF (64-bit big-endian)
• 0xCFFAEDFE (64-bit little-endian)
• 0xCAFEBABE (universal)

with the added complication that 0xCAFEBABE is also used by Java class files. Distinguishing between the two ​involves additionally checking the second set of four bytes: if less than 0x00000020, then it's Mach-O.

Alternately, MacPorts does install /opt/local/libexec/macports/lib/tcllib2.0/fumagic which provides fileutil::magic::filetype, a Tcl implementation of file; we might conceivably use that instead of writing our own.

Elsewhere in the muniversal portgroups we make decisions based on filename extensions, which could potentially be improved by using proper magic-number-based filetype identification.