muniversal fails on static libraries built with clang-17 -ffat-tlo-objects

[RJVB (René Bertin)]

Clang-17 introduced the -ffat-lto-objects option with which GCC long allowed to create object files (and thus static libraries, "archives") that contain both regular object code and the kind of bitcode they use for LTO builds.

Older versions of lipo will not recognise this format, and libtool (the next step in the muniversal merge stage) doesn't either. EDIT: it is conceivable that the same applies to archives containing fat objects generated by GCC.

However, lipo will happily merge the archives when told what architecture each file is.

The merge routine gets called with the 2 source directories but also with the 2 architectures. Supposing it is desirable to use lipo's built-in arch. recognition during the 1st attempt it would be easy to add a second attempt using lipo. In pseudo-code:

if arch1 in dir1 then arch1opt="-arch ${arch1}"
if arch2 in dir2 then arch2opt="-arch ${arch2}"

if !catch lipo dir1/file1 dir2/file2 -output dir/file
elseif !catch lipo arch1opt dir1/file1 arch2opt dir2/file2 -output dir/file
elseif !catch libtool <etc>

checking if arch1opt and/or arch2opt are not empty would be redundant; if not there will simply be 2 failed lipo attempt (as there will be when lipo simply doesn't support the kind of file at all).

Additionally I think muniversal ought to invoke $prefix/bin/lipo and/or $prefix/bin/libtool if they're installed, to benefit from new features or bug fixes. IMHO this can be a gratuitous build dependency in general, while ports that actually require newer versions than those provided by the system can add a build dependency on port:cctools.