[MacPorts] #69380: libffi fails on 10.5 PPC for bad patch
MacPorts
noreply at macports.org
Sat Feb 24 04:48:02 UTC 2024
#69380: libffi fails on 10.5 PPC for bad patch
-----------------------+-------------------------
Reporter: rmottola | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords: leopard ppc
Port: libffi |
-----------------------+-------------------------
Comment (by fhgwright):
Replying to [comment:3 rmottola]:
> Being the patch for intel only, I removed it as a test from the portfile
and it compiled on PPC.
In general, conditionally-applied patches are a bad idea. If at all
possible, any conditional behavior of patches should be ''within'' the
patches, not in whether to apply them. The idea is to create a single set
of modified sources that works in all cases. Ideally, this should even
mean being acceptable for non-Mac systems, with the goal of being
acceptable as upstream changes (whether or not upstream actually accepts
them).
And version updates should revalidate patches, and update them as needed.
Messages like
{{{
Hunk #3 succeeded at 1262 with fuzz 2 (offset 142 lines).
}}}
mean that someone hasn't done their homework.
Replying to [comment:8 kencu]:
> That ain’t good, as libffi needs to work….it underpins a number of other
ports.
Sort of, though it's sometimes only for ancillary uses. For example, the
`llvm` port depends on `libffi`, but AFAIK the core compiler part of
`llvm` doesn't use `libffi` - it's just for things like the language
bindings. If the port were properly partitioned into core and extras
subports,there would be no issue with circular dependencies even when
building with `clang`, since the dependency chain would then look like:
{{{
llvm-extras -> libffi -> clang -> llvm-core
}}}
I see that `clang-3.*` have dependencies on `libffi`, but I'm not sure if
those are legit. More recent versions of `clang` don't.
Replying to [comment:14 ballapete]:
> I think `libff @3.4.6` works fine! I "played" a bit with make/gmake in
`testsuite/libffi.bhaible`, built the two test programmes and ran them
manually. The results, the failures, are these:
>
> {{{
> ...
> }}}
>
> I think this can be expected. The `PowerPC G4 CPU` is only 32 bit.
Possibly this physical limitation produces the failures. Using a different
math library might resolve the issues…
The integer bitness doesn't affect the floating-point bitness, and there's
no math library involved when doing basic FP on a CPU with FP hardware.
What `libffi` has to get right is the way that various function arguments
and results of various types are passed around on the stack and in
registers. The ABI docs often fail to spell out the corner cases
adequately, and sometimes `libffi` guesses wrong.
--
Ticket URL: <https://trac.macports.org/ticket/69380#comment:18>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list