[MacPorts] #71668: libffi @3.4.6; Build Failure

[MacPorts]

#71668: libffi @3.4.6;  Build Failure
-----------------------+-----------------------
  Reporter:  hardincj  |      Owner:  fhgwright
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.10.5
Resolution:            |   Keywords:
      Port:  libffi    |
-----------------------+-----------------------

Comment (by fhgwright):

 Replying to [comment:2 ryandesign]:
 > You say you are on an Apple Silicon Mac and that seems to be confirmed
 by the line in the log which says:
 >
 > {{{
 > :debug:sysinfo macOS 15.2 (darwin/24.2.0) arch arm
 > }}}
 >
 > but it is also contradicted by the log lines that say:
 >
 > {{{
 > :info:configure checking build system type... x86_64-apple-darwin24.2.0
 > :info:configure checking host system type... x86_64-apple-darwin24.2.0
 > :info:configure checking target system type... x86_64-apple-darwin24.2.0
 > :info:configure continue configure in default builddir "./x86_64-apple-
 darwin24.2.0"
 > :info:configure ....exec /bin/sh .././configure "--srcdir=.." "--enable-
 builddir=x86_64-apple-darwin24.2.0" "darwin24.2.0"
 > :info:configure checking build system type... x86_64-apple-darwin24.2.0
 > :info:configure checking host system type... x86_64-apple-darwin24.2.0
 > :info:configure checking target system type... x86_64-apple-darwin24.2.0
 > }}}
 >
 > This should not be. Are you perhaps using an Intel terminal program or
 shell? If so, please run `sudo port clean libffi` and then try again in an
 Apple Silicon terminal and shell.

 Presumably if the relevant terminal/shell were a universal build, then
 this wouldn't happen.

 Some projects' build procedures like to make their own architecture
 determinations, ignoring supplied settings.  Perhaps this is one such
 project.  It occurs to me that it might be a useful feature for a Portfile
 to be able to request that all toolchain programs be launched via an
 `arch` command, to at least avoid the most obvious forms of this issue.
 It could be part of the compiler wrapper stuff (which is highly overused
 but nevertheless probably useful in this context).

 Meanwhile, I'll look into fixing this in a more port-specific way.
 Though, since I normally only submit fully-tested PRs, and my PPC machine
 isn't expected to finish the `gcc14` "upgrade" until 02-Jan, I won't be
 submitting anything before then.

 Aside from the apparent architecture screwup, if there's a problem with
 `libffi` on `x86_64`, that's a bug, anyway, but first-order, it looks like
 just a problem with architecture fickleness.

 It would also be helpful if base did a better job of supporting Rosetta-
 based setups.  Merely setting `build_arch` to the emulated target works
 for some things, but not for things that use constructs like `platform
 <arch>`.

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