libffi @3.4.6: Build failure on arm64, configure detects x86_64

[hardincj]

libffi fails to build on new Apple Macintosh Mini:

• Apple Silicon M4 Pro chip
• MacOS Sequoia 15.2
• Xcode version 16.2

Build messages:

hardincj@Mac libffi % sudo port install libffi
--->  Fetching archive for libffi
--->  Attempting to fetch libffi-3.4.6_1.darwin_24.arm64.tbz2 from https://packages.macports.org/libffi
--->  Attempting to fetch libffi-3.4.6_1.darwin_24.arm64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/libffi
--->  Attempting to fetch libffi-3.4.6_1.darwin_24.arm64.tbz2 from http://bos.us.packages.macports.org/libffi
--->  Building libffi
Error: Failed to build libffi: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port libffi failed

main.log is attached.

[hardincj]

Main.log output file

[ryandesign (Ryan Carsten Schmidt)]

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.

[fhgwright (Fred Wright)]

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

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

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

Not necessarily. The user may have deliberately told the terminal to open in Rosetta. See #71080 for one previous instance of that; there have been others.

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.

As far as I know there isn't a general problem building libffi for x86_64 on x86_64 nor on arm64 for arm64 (based on the all-green ​build status of libffi, if that page will load for you), but there may be a problem cross-compiling some ports like libffi for arm64 on x86_64, which is effectively what's happening here. MacPorts should support cross-compiling but in many cases like this it doesn't work well. Users will encounter a better experience by not attempting to cross-compile.

It would also be helpful if base did a better job of supporting Rosetta-based setups.

Josh already added several accommodations for Rosetta-based setups in recent MacPorts base versions, which surprised me because I don't think we should be encouraging the practice.

[fhgwright (Fred Wright)]

Replying to ryandesign:

Replying to fhgwright:

It would also be helpful if base did a better job of supporting Rosetta-based setups.

Josh already added several accommodations for Rosetta-based setups in recent MacPorts base versions, which surprised me because I don't think we should be encouraging the practice.

Huh? Why would you possibly want to discourage port developers from testing on as many configurations as possible, including hardware they don't have.

[jmroot (Joshua Root)]

Replying to ryandesign:

Josh already added several accommodations for Rosetta-based setups in recent MacPorts base versions, which surprised me because I don't think we should be encouraging the practice.

The main thing I did was ensure that base is running natively when it should be. The build_arch=x86_64 under Rosetta case was more left as an exception to the native re-execution norm, because that wouldn't help and might harm.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

Huh? Why would you possibly want to discourage port developers from testing on as many configurations as possible, including hardware they don't have.

I want to discourage users of Apple Silicon systems from configuring their terminals to run in Rosetta emulation because I cannot imagine any reason why they would do that, and because it decreases performance, and because it causes MacPorts to work improperly.

Replying to jmroot:

The build_arch=x86_64 under Rosetta case was more left as an exception to the native re-execution norm, because that wouldn't help and might harm.

build_arch isn't x86_64 in this ticket; it's arm64, but for some reason the libffi build is detecting an x86_64 system, and the reason I have posited, which we are still waiting to hear back from the user to confirm but which has been the cause of similar problems in at least two other tickets, is that they may be using an x86_64 terminal and/or shell, and my suggested solution for the user would be to use an arm64 terminal and shell.

[jmroot (Joshua Root)]

Replying to ryandesign:

build_arch isn't x86_64 in this ticket; it's arm64, but for some reason the libffi build is detecting an x86_64 system, and the reason I have posited, which we are still waiting to hear back from the user to confirm but which has been the cause of similar problems in at least two other tickets, is that they may be using an x86_64 terminal and/or shell, and my suggested solution for the user would be to use an arm64 terminal and shell.

And I'm saying that it's very difficult for that to happen the way it used to, because base will always try to ensure that it is not running under Rosetta if build_arch is arm64. And indeed this indicates that base is running natively:

:debug:sysinfo macOS 15.2 (darwin/24.2.0) arch arm

The terminal's arch shouldn't have any effect, but if /bin/sh or sandbox-exec are somehow x86_64 only that could explain the observed symptom.

[hardincj]

OK - a lot of comments overnight - let me try to answer some of the questions.

1. Hardware is definitely ARM64. I'm not intentionally trying to run anything with an x86_64 setting, but that doesn't mean that there isn't still some other port that was compiled as x86_64 that is the cause of that entry in the log.

2. The terminal program is the default MacOS Terminal program, running zsh. I don't see any reason why it would be running under Rosetta. I checked 'Activity Monitor' just now, and it identifies Terminal as 'Apple', not 'Intel'.

3. This system was recently upgraded from an x86_64 processor to an Apple Silicon M4 processor (i.e. I copied it over from old machine to this one). I followed the instructions on one of the MacPorts.org pages that talk about migration to a new computer, including running 'sudo port migrate'. A lot of ports were reinstalled in that process.

4. I had checked the build status page mentioned above, and noted that while the port health entries are mostly green, the entry for 'Sequoia (ARM64)' shows up as '?'. That was part of the reason I chose to submit the ticket - it looked like it hadn't been tested yet.

All that said, I took Ryan's original advice and just ran 'sudo port clean libffi', and then re-ran a normal install. The install ran clean with no errors, so I think we can close this ticket. I'm just guessing, but it seems likely that some remnant from before the migration was causing the previous problems. Once it was cleaned out, everything seems OK. Thank you very much for the help.

[fhgwright (Fred Wright)]

Replying to hardincj:

OK - a lot of comments overnight - let me try to answer some of the questions.

[...]

4. I had checked the build status page mentioned above, and noted that while the port health entries are mostly green, the entry for 'Sequoia (ARM64)' shows up as '?'. That was part of the reason I chose to submit the ticket - it looked like it hadn't been tested yet.

I imagine that all 'Sequoia (ARM64)' entries are '?', given that there's no buildbot for 'Sequoia (ARM64)'. The buildbot landscape for arm64 is deficient at both ends of the OS scale.

It builds fine for that configuration here, including +universal. It doesn't pass its tests, which is in general par for the course for libffi, but in this case the main problem is a known bug in dejagnu.

All that said, I took Ryan's original advice and just ran 'sudo port clean libffi', and then re-ran a normal install. The install ran clean with no errors, so I think we can close this ticket. I'm just guessing, but it seems likely that some remnant from before the migration was causing the previous problems. Once it was cleaned out, everything seems OK. Thank you very much for the help.

Maybe there's an arch-related bug in port migrate, though it's not clear how reproducible it is.

[ryandesign (Ryan Carsten Schmidt)]

The lines in the log where the configure script determined an x86_64 host are the first lines of the configure phase. They are a standard part of autoconf-based configure scripts. The value is determined by running config.guess, which bases its values on uname. So I don't see how this can have had anything to do with a migration-related bug since config.guess is shipped with libffi and uname is part of macOS; no other ports would be involved.

The log shows several attempts to install the port. The first one is the one where the configure phase ran and determined an x86_64 host. That was on Sat Dec 14 23:07:47 EST 2024. All subsequent attempts reused the December 14 configure phase results. @hardincj, are you absolutely certain that when you were attempting the libffi build on December 14, you were in an Apple Silicon terminal and shell? Because I cannot think of any way for this result to happen unless you were in an Intel shell. You said you're using Apple Terminal… was that the case on December 14 as well? Is the Open in Rosetta checkbox checked if you Get Info on Terminal (or the terminal you were using on December 14) in the Finder, or rather was it checked on December 14? Were you using /bin/zsh for your shell on December 14 or perhaps a different shell that was compiled for Intel—perhaps a MacPorts-installed copy of bash or zsh that had not yet been rebuilt by migration?

[hardincj]

The 12/14 date is right about when I switched from the Intel-based Mac Mini to an Apple Silicon Mac Mini. It's entirely possible that the first attempt to install was done on that system (Sorry - that was over 2 weeks ago - can't be more specific than that). And if that config file stayed in place until I ran the 'clean' command, then that seems to explain what happened here.

[ryandesign (Ryan Carsten Schmidt)]

Replying to hardincj:

The 12/14 date is right about when I switched from the Intel-based Mac Mini to an Apple Silicon Mac Mini. It's entirely possible that the first attempt to install was done on that system

No, the log shows that all attempts including the first one were done on macOS 15.2 (darwin/24.2.0) arch arm.

[hardincj]

Is there any possibility that this could have resulted from attempting the first install before running the 'migrate' command? I wasn't aware of the details of doing a migration until I did this upgrade, so it's possible I attempted an install before running 'migrate'.

[ryandesign (Ryan Carsten Schmidt)]

I'm not sure. port migrate is a brand new subcommand that I've never used and I haven't read about all that it does.

[jmroot (Joshua Root)]

Could be, if the previous attempt was with an older MacPorts version under Rosetta or on the old x86_64 system and the build directory got copied over. port migrate will clean before building but only for the ports that it actually rebuilds.

[fhgwright (Fred Wright)]

I thought this had been determined to be due to some kind of screwed-up state. It works fine here. Successful build log available upon request. Vitals:

DEBUG: Starting logging for libffi @3.4.6_1
DEBUG: macOS 15.3.1 (darwin/24.3.0) arch arm
DEBUG: MacPorts 2.10.5
DEBUG: Xcode 16.2, CLT 16.2.0.0.1.1733547573
DEBUG: SDK 15
DEBUG: MACOSX_DEPLOYMENT_TARGET: 15.0

BTW, there's a new version (3.4.7) of libffi available, but I've held off on updating the port, pending investigation of why the test behavior is substantially worse than 3.4.6.

[yretenai]

For what it's worth, this same error happens when intentionally trying to build x86_64 libffi on arm (on tahoe.) The same failed to locate symbol list. Not sure if I should open a separate issue.

So it seems libffi on arm is ​just broken; Apple apparently has their ​own libffi with workarounds.

As for build status, it is weird because the ​arm builds are reporting a build time of 0 seconds, while the ​x86_64 builds are reporting 28 seconds, but there are binary packages being uploaded so it is definitely working somewhere...

(Unfortunately no darwin 24 x86-64 builds, though.)

[fhgwright (Fred Wright)]

Actually, I just tested it (v3.4.8) on Tahoe here, and it builds fine (+/-universal). Tests are a different story as usual.

If you're trying to build x86_64 on arm by setting build_arch to x86_64, you're probably in for a world of hurt. Although Rosetta-targeted builds work in a few cases via this method, they often don't due to architecture checks that don't go by build_arch.