[MacPorts] #69715: muniversal fails on static libraries built with clang-17 -ffat-tlo-objects

[MacPorts]

#69715: muniversal fails on static libraries built with clang-17 -ffat-tlo-objects
---------------------+--------------------
  Reporter:  RJVB    |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------
Description changed by RJVB:

Old description:

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

New description:

 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.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/69715#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS