[MacPorts] #61170: libffi @3.3_1 fails to build on 10.5 i386
MacPorts
noreply at macports.org
Wed Sep 16 22:04:43 UTC 2020
#61170: libffi @3.3_1 fails to build on 10.5 i386
------------------------+---------------------
Reporter: fhgwright | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.6.3
Resolution: | Keywords: leopard
Port: libffi |
------------------------+---------------------
Comment (by fhgwright):
> The recommendation for Leopard i386 is to set the universal archs to
"i386 x86_64".
> Then it works exactly like SnowLeopard, and the portfiles all work
properly. (Pretty much -- you have to do LibcxxOnOlderSystems manually if
you want to use libc++)
Having to change the configuration is more onerous than having to manually
install a non-default variant. Note that I wasn't trying to do anything
with `libcxx` explicitly at all - this is just what happens when
populating a new MacPorts install from scratch.
The cheap fix would probably be just to make `libcxx -universal ` the
default in cases where `+universal` causes trouble. The only advantage I
can see to the `+universal` default at all is to make it available as a
binary archive, but binary archives have never been offered in the
relevant cases, anyway.
Defaulting to `+universal` should be done very sparingly in general, at
least until `+universal` stops virally infecting all the build
dependencies and causing massive build times.
> disabling compact unwind and building with clang-3.4 is clean, though:
> `configure.ldflags-append -Wl,-no_compact_unwind`
> maybe that would help the build with gas succeed to link...
Another question is whether a MacPorts `cctools` built with `Xcode gcc`
would assemble this correctly. That flavor of `cctools` isn't currently
available, since `cctools +xcode` just copies the `cctools` from `Xcode`
instead of building it. If that approach does work, it would probably
need to be something like `cctools-bootstrap`, to avoid variant conflicts
with the "real" `cctools`. Yes, another bootstrap kludge, but nowhere
near as onerous as keeping an old `libffi` around. And building with
MacPorts `cctools` would behave more consistently than relying on varying
`Xcode gcc/gas` versions.
I presume the "unwind" here is unrelated to `libunwind`, though `libffi`
seems to have an undeclared configure dependency on `libunwind`. If
`libunwind -universal` is active, then `libffi +universal` fails to
configure, because "check if C compiler can make executables"
opportunistically links against `libunwind` and fails if it's missing the
needed architecture. But with `libunwind` inactive, `libffi +universal`
builds fine. This is on 10.9, and has nothing to do with the current
issue.
--
Ticket URL: <https://trac.macports.org/ticket/61170#comment:23>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list