libffi fails on 10.5 PPC for bad patch

[rmottola (Riccardo)]

issue applying patches

patching file src/powerpc/darwin.S
patching file src/powerpc/darwin_closure.S
--->  Applying patch-libffi-intel-leopard-sysv.diff
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/libffi/files/patch-libffi-intel-leopard-sysv.diff'
patching file ./src/x86/sysv.S
Hunk #1 FAILED at 792.
Hunk #2 FAILED at 820.
Hunk #3 succeeded at 1262 with fuzz 2 (offset 142 lines).
2 out of 3 hunks FAILED -- saving rejects to file ./src/x86/sysv.S.rej
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/libffi/files/patch-libffi-intel-leopard-sysv.diff'

[rmottola (Riccardo)]

I wonder why I don't have this issue on intel 10.5, even if the patch is specific to it. Perhaps it defaults building to clang and thus gets skipped?

[rmottola (Riccardo)]

Being the patch for intel only, I removed it as a test from the portfile and it compiled on PPC.

[ryandesign (Ryan Carsten Schmidt)]

There is some more discussion about this new patch failure starting at comment:ticket:61170:32 but the discussion should continue in this new ticket.

[ballapete (Peter "Pete" Dyballa)]

The contents of that old patch has been incorporated into the sources ​upstream, around Christmas 2022. The problem left is that tests fail… Here on Sonoma 14.2.1 :

                === libffi Summary ===

# of expected passes            1632
# of unexpected failures        4
make[3]: *** [check-DEJAGNU] Error 1
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6" && /usr/bin/make check

[kencu (Ken)]

I saw 6 failing tests on Sonoma arm64, in the go closures I recall.

This is minor, and these can be taken upstream to sort out.

More concerning were the hundreds of failures you reported on older systems in the other ticket.

That ain’t good, as libffi needs to work….it underpins a number of other ports.

[rmottola (Riccardo)]

libffi is a very base building block indeed. Is it possible to run tests easily? I have at hand a couple of systems where, once the patch is removed, things build and isntall, but I don't know the reliability yet, since 10.5 has many more problematic packages before being able to test full apps.

[ballapete (Peter "Pete" Dyballa)]

Replying to rmottola:

libffi is a very base building block indeed. Is it possible to run tests easily?

Sometimes: Yes! Just try port test <port name>.

Other times Portfile is not prepared for testing the just built software. Then you would to check whether the software itself provides tests. This can be performed this was:

0. I am an amateur. Could be there are easier ways.

1. Run port -vs build <port name>. The option -s is not really necessary. To buildsomething port would need to fetch, extract, potentially patch, and finally configure the software's sources. The option -v provides some output of what port is performing. (You could even add the option -d to make port output some debug messages about its work.) (Another option could be -k to make port keep the software, usually needed when built software can be installed for a first time or just upgraded. This inherently cleans the working directory.)

2. When the software has built successfully you might keep the window where it was built, where output from this is saved. It contains this or that useful information.

3. It is useful to open a new Terminal or whatever window for the next step. The build window contains quite early a line starting with 'Executing: cd "/opt/…" && configure …'. You could just copy the cd command (until " &&", but not including these three characters, the double quotes do not matter) and paste it on the command line (or Terminal, GNU Emacs, whatever gives you a shell with prompt and a command line). This way you change your working directory to where the software was built

port itself can give you a hint where this happened: port work 'port name'. The output path name always ends in work. You will have to add at least one more component, which the shell's command line can add upon file name completion action, which is typing cd, a SPACE character, and then pasting the output of port work 'port name'. To complete this path (or file) name you type TAB. When no choice is left, i.e. there is only more component existing to extend the lengthy path name, this one is automatically added. When alternatives exist, these are shown and you need to choose and type at least as many characters of your choice that shell will know that upon next TAB it can only expand to one unique and unambiguous name.

4. In the software's build directory a file Makefile will exist. It contains so-called targets, marked with a COLON at the end of the target's name. Such targets can be check or test. One of them will perform the tests. On the command line they are invoked as make test or make check. Then some unpredictable output can happen…

5. Try and learn! You can look inside Makefile with some text editor (vi, nano, pico, whatever) best in read-only mode. Once you understand the instructions for make (or gmake), kept on the lines below the target's name, you can understand which additional utilities might get invoked (your system might be missing, expect for example) or whatever internal software will be built to perform the tests.

6. Choose some other ports to learn more.

7. When finished, perform port clean 'port name' to remove the software tree. Before you can always invoke port install 'port name' or port upgrade 'port name'. Running any of these three will remove the working directory where you invoked make test or make check. The shell or command line will become unusable. To keep it usable just invoke cd before you start cleaning, installing, or upgrading.

Does this "recipe" help a bit?

[ballapete (Peter "Pete" Dyballa)]

The many failures to test on Leopard or Tiger come using any of these three compiler warnings that GCC 4.2 does not understand: -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized.

IMO this is a -non-brainer. The warnings are OK when developing a software, not when using´ it, for example in a test case. When perfoming make test` they should disappear.

[ballapete (Peter "Pete" Dyballa)]

There is one old patch from #61170 from three years ago that has to be patched for Tiger and Leopard (at least): patch-libffi-tests-gcc42.diff. It (still or again) leads to:

cc1: error: unrecognized command line option "-Wno-unused-command-line-argument"

[ballapete (Peter "Pete" Dyballa)]

With the updated patch, patch-libffi-tests-GCC42.diff (capital "GCC" instead of "gcc"), the test output looks better on PPC Leopard, Mac OS X 10.5.8:

		=== libffi Summary ===

# of expected passes		444
# of unexpected failures	170
# of unsupported tests		209

What's left are:

../../testsuite/libffi.bhaible/test-call.c:35:
ffitest39035.c:5:3: error: #error Failed #ifdef __i386__
ffitest39035.c:5:3: error: #error Failed #ifdef FFI_TARGET_HAS_COMPLEX_TYPE
ffitest39035.c:5:3: error: #error Failed #ifdef FFI_GO_CLOSURES

The first line line is mentioned a few thousand times, the second line a few hundred times, and the last two lines are singles.

[ballapete (Peter "Pete" Dyballa)]

Updated patch to let a few test PASS on PPC Leopard (and Tiger presumingly too)

[ballapete (Peter "Pete" Dyballa)]

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:

pete 278 /\ cat failed-call
Float f(Float,float,double):({0.1},0.2,0.3)->{0.6}
Float f(Float,float,double):({0.2},0.3,-9.80879e-154)->{0.5}
Double f(float,Double,double):(0.1,{0.2},0.3)->{0.6}
Double f(float,Double,double):(0.1,{0.3},-9.80879e-154)->{0.4}
Double f(Double,float,double):({0.1},0.2,0.3)->{0.6}
Double f(Double,float,double):({0.2},0.3,-9.80879e-154)->{0.5}
pete 279 /\ cat failed-callback 
Float f(Float,float,double):({0.1},0.2,0.3)->{0.6}
Float f(Float,float,double):({-1.99908},0.1,0.2)->{-1.69908}
Double f(float,Double,double):(0.1,{0.2},0.3)->{0.6}
Double f(float,Double,double):(0.1,{6.52217e-310},0.2)->{0.3}
Double f(Double,float,double):({0.1},0.2,0.3)->{0.6}
Double f(Double,float,double):({-1.99264},0.1,0.2)->{-1.69264}

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…

[ballapete (Peter "Pete" Dyballa)]

On Tiger testsuite/libffi.bhaible/Makefile will need an additional patch: LDFLAGS contains -Wl,-rpath…

[rmottola (Riccardo)]

A lot of parallel work, I was behind. I tested the old portifle, not the new patch and confirm that this:

:info:test # of unexpected failures     298
:info:test # of unresolved testcases    298
:info:test # of unsupported tests               209

is happening on 10.5/x86_64 10.5/i386 and 10.5/ppc32 (which are the three archs I can thest on). Given the warning explanation, it makes sense. Next week I can try on all system the patch, if they settle in the meanwhile or even if you update the patch in the portfile (the old one is broken anyway)

[ballapete (Peter "Pete" Dyballa)]

Replying to rmottola:

if you update the patch in the portfile (the old one is broken anyway)

To make it clear: patch-libffi-intel-leopard-sysv.diff is superfluous since its contents has been incorporated into the sources. patch-libffi-tests-gcc42.diff can easily be substituted with patch-libffi-tests-GCC42.diff which is kind of an update. You can change Portfile easily yourself: sudo port edit libffi. I do not know (or remember) how to set the editor in which it will open. Maybe sudo env EDITOR=<your choice> port edit libffi on the command line will do exactly what you want.

[fhgwright (Fred Wright)]

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

[ballapete (Peter "Pete" Dyballa)]

Replying to fhgwright:

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

I stick to my limitations. As with Wikipedia, I appreciate every improvement of my articles. Or patches…

[rmottola (Riccardo)]

Replying to ballapete:

Replying to rmottola:

if you update the patch in the portfile (the old one is broken anyway)

To make it clear: patch-libffi-intel-leopard-sysv.diff is superfluous since its contents has been incorporated into the sources. patch-libffi-tests-gcc42.diff can easily be substituted with patch-libffi-tests-GCC42.diff which is kind of an update. You can change Portfile easily yourself: sudo port edit libffi. I do not know (or remember) how to set the editor in which it will open. Maybe sudo env EDITOR=<your choice> port edit libffi on the command line will do exactly what you want.

Yes. It was clear. Today I proceeded as following. Got the "GCC42" patch and replaced in the portfile the gcc42 file with it. Disabled the intel-leopard patch.

I tested on PPC G4 and got:

# of expected passes            444
# of unexpected failures        170
# of unsupported tests          209

and on PPC intel 64bit:

# of unexpected failures        298
# of unresolved testcases       298
# of unsupported tests          209

Interesting that the total is different, that things changed on PPC and not on Intel-64.

[ballapete (Peter "Pete" Dyballa)]

There might be a cause for testing on PPC more than on other hardware: Different ways to store (real world) multi-byte data, MSB vs. LSB. OTOH, there could be the same problem that I addressed in my updated GCC42 patch: Inadequate compiler options. I could only solve the PPC problems…

For intel you might look into the LOG files in the testsuite directory. On my PowerBook G4 the path name is /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/powerpc-apple-darwin9.8.0/testsuite, which is built from the output of port work libffi, i.e. /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work (it codes the RSYNC server in path name), + libffi-3.4.6/powerpc-apple-darwin9.8.0/testsuite. Again, there is a component, powerpc-apple-darwin9.8.0, that has to be adapted for intel, which might be x86_64-apple-darwin9.8.0. Anyway, you can find the proper name by invoking on the command line: "ls -l port work libffi/libffi-3.4.6 | egrep '^{d'" (the whole text between double quotes, which might have a problem, because the combination of} (CARET) and TEXT following makes the TEXT displayed as a superscript…).

A second directory to look into is "port work libffi/libffi-3.4.6/testsuite/libffi.bhaible".

[fhgwright (Fred Wright)]

Replying to ballapete:

There might be a cause for testing on PPC more than on other hardware: Different ways to store (real world) multi-byte data, MSB vs. LSB. OTOH, there could be the same problem that I addressed in my updated GCC42 patch: Inadequate compiler options. I could only solve the PPC problems…

Actually, back when I was wrestling with libffi issues, I found that the most troublesome architecture was i386. This may be because it's the most register-starved architecture, and hence the one with the kludgiest ABI.

That was a few years ago, and I'd come up with three fixes for Portfile issues before going down a large rabbit hole trying to fix all the test failures, and eventually putting the whole thing aside. It seems that at least two of the Portfile fixes are still relevant, and I'm reserving judgment on the third pending further testing.

I'll clean up the conditional patchfile mess shortly, and then look into how many of the test failures are practical to fix in the short term.

Someone with write access can feel free to assign this ticket to me; I can't do it myself.

[ballapete (Peter "Pete" Dyballa)]

Replying to fhgwright:

Replying to ballapete:

Actually, back when I was wrestling with libffi issues, I found that the most troublesome architecture was i386. This may be because it's the most register-starved architecture, and hence the one with the kludgiest ABI.

With my first answer sentence I wanted to express that G4 and G5 can handle both sorts of data MSB, as coming from earlier Motorola processors, and LSB, as used in the i386/x86 world. This could lead to more tests for PPC. Another case is that G4 is some kind of "64 bit aware" while G5 is 64 bit. I am not sure whether Riccardo cites "64bit" correctly for his test results. Is his intel CPU 64 bit? If not then 64 bit tests are useless and would not be run, decreasing the number of tests performed. On my modern MacBook the number of tests is also quite low, which might indicate that this family of intel processors has less things to test.

But actually I have no idea of what the tests are!

[rmottola (Riccardo)]

@ballapete yes, I have an intel 64bit laptop running 10.5, a rare combination, but works. Installed for mostly test purposes, but acts quite well. The computer could run 10.6, but I have anotherone with 10.6. I also have a 32bit 10.5 intel.

So it is possible to test 10.5 without 32bit issues. While 10.5 is mostly used on old 32bit computer, a lot of software today is mainly programmed on 64bit.

Said that, I see several kinds of warnings in the tessuite log:

../../testsuite/libffi.bhaible/test-call.c:35: warning: unused parameter �~@~Xstream�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xa�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xb�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xc�~@~Y^M

... (repeated for dozens of lines)

but also this which looks worse:

ld warning: in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/i386-apple-darwin9.8.0/.libs/libffi.dylib, file is not of required architecture^M
Undefined symbols:^M
  "_ffi_type_void", referenced from:^M
      _ffi_type_void$non_lazy_ptr in ccXofqb0.o^M
  "_ffi_type_sint8", referenced from:^M
      _ffi_type_sint8$non_lazy_ptr in ccXofqb0.o^M
  "_ffi_call", referenced from:^M
      _void_tests in ccXofqb0.o^M
  "_ffi_type_sint32", referenced from:^M
      _ffi_type_sint32$non_lazy_ptr in ccXofqb0.o^M
  "_ffi_prep_cif", referenced from:^M
      _void_tests in ccXofqb0.o^M
ld: symbol(s) not found^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=1 -O0 (test for excess errors)
Excess errors:

[ballapete (Peter "Pete" Dyballa)]

Replying to rmottola:

Said that, I see several kinds of warnings in the tessuite log:

../../testsuite/libffi.bhaible/test-call.c:35: warning: unused parameter �~@~Xstream�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xa�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xb�~@~Y^M
../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter �~@~Xc�~@~Y^M

... (repeated for dozens of lines)

This is in my opinion harmless. It's just a warning, and the strange text comes from different multi-byte character encodings in some file and in your terminal application and no means were taken to re-encode the file's contents for display use.

but also this which looks worse:

ld warning: in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/i386-apple-darwin9.8.0/.libs/libffi.dylib, file is not of required architecture^M
Undefined symbols:^M

That's a real failure. Maybe it helps to build, install, test libffi +universal. This might produce "fat" libraries with 32-bit and 64-bit versions in one library file. OTOH, the question is, why is some test routine assuming a 64 bit architecture, i.e. x86_64-apple-darwin9.8.0? As far as I understand libffi a configure script determines the underlying architecture and records it in files and directory names. So there should not exist either a need or a cause to switch the architectures…

There is a small utility, file, that can determine which kind a "file" is (and in UNIX everything is assumed to be a file in some file system). Its usage would be:

file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/i386-apple-darwin9.8.0/.libs/libffi.dylib

[ballapete (Peter "Pete" Dyballa)]

On macOS High Sierra, Version 10.13.6 I get from port test libffi:

Using ../../testsuite/lib/libffi.exp as tool init file.
Test run by root on Tue Feb 27 11:16:56 2024
Native configuration is x86_64-apple-darwin17.7.0

		=== libffi tests ===

Schedule of variations:
    unix

Running target unix
Using /opt/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /opt/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../testsuite/config/default.exp as tool-and-target-specific interface file.
Running ../../testsuite/libffi.bhaible/bhaible.exp ...
Running ../../testsuite/libffi.call/call.exp ...
Running ../../testsuite/libffi.closures/closure.exp ...
Running ../../testsuite/libffi.complex/complex.exp ...
Running ../../testsuite/libffi.go/go.exp ...

		=== libffi Summary ===

# of expected passes		1636

[fhgwright (Fred Wright)]

Replying to ballapete:

Replying to fhgwright:

Replying to ballapete:

Actually, back when I was wrestling with libffi issues, I found that the most troublesome architecture was i386. This may be because it's the most register-starved architecture, and hence the one with the kludgiest ABI.

With my first answer sentence I wanted to express that G4 and G5 can handle both sorts of data MSB, as coming from earlier Motorola processors, and LSB, as used in the i386/x86 world. This could lead to more tests for PPC.

While it's true that PPC processors have cross-endian loads and stores, that's completely irrelevant in this context, since there's nothing cross-endian about libffi.

Another case is that G4 is some kind of "64 bit aware" while G5 is 64 bit.

I don't know what you mean by "64-bit aware". The G4 is a pure 32-bit processor, just like i386 (or 32-bit arm, for that matter). While the C language has supported 64-bit operations on 32-bit processors since C99, that's done by generating double-precision machine code, not by any "64-bit awareness" of the CPU (beyond support for multiprecision operations in general, which pretty much all CPUs have).

I am not sure whether Riccardo cites "64bit" correctly for his test results. Is his intel CPU 64 bit? If not then 64 bit tests are useless and would not be run, decreasing the number of tests performed. On my modern MacBook the number of tests is also quite low, which might indicate that this family of intel processors has less things to test.

AFAIK, libffi has no "64-bit tests" specifically, but just runs the tests on whatever architecture it's built for. In universal builds, the tests are run on each architecture separately (for all built architectures that are executable on the host).

But actually I have no idea of what the tests are!

Use the source, Luke! :-)

[fhgwright (Fred Wright)]

I decided not to hold up submitting a PR pending fixing additional test issues, so I submitted one that just fixes the patch stuff and incorporates versions of a few Portfile fixes that I'd had from before. It's at ​https://github.com/macports/macports-ports/pull/22860.

Still to be done is going through my old fixes for libffi itself and seeing which of them are still applicable.

[ballapete (Peter "Pete" Dyballa)]

Replying to fhgwright:

Replying to ballapete:

Another case is that G4 is some kind of "64 bit aware" while G5 is 64 bit.

I don't know what you mean by "64-bit aware".

It is citing the text of an ad, 25 years ago, for the first PowerBook G4. Maybe it was describing the properties of C99, maybe it's just the abundance of registers in PowerPC. Two 32 bit registers give one 64 bit register – I assumed that PowerPC had more prospects than intel.

But actually I have no idea of what the tests are!

Use the source, Luke! :-)

Ah, here we have fresh and clean tap water in abundance… No need of polluted sources! (Or methane in tap water.)

[fhgwright (Fred Wright)]

In e6290f04ddc0ed740127985bde4498ff9d36b6bd/macports-ports (master):

libffi: Fix build on 10.4, 10.5

This makes three changes to the patches for 10.4 and 10.5:

1) In the G3 patch, it removes the ppc7400 reference that was never
actually used, rather than updating it. It still fixes the case that
is actually used.

2) It removes the patch for i386 assembler that has been
(approximately) incorporated upstream since v3.4.5. The collision
with this patch was the reason for the patch failure.

3) For the gcc 4.2 test-build fix, it replaces the conditionally
applied patchfile with an unconditional patch controlled by an
environment variable, thereby keeping the source code consistent
across OS versions. This new environment variable is now defined by
the Portfile when the compiler is gcc 4.2.

The patches for ​https://github.com/macports/macports-ports/pull/1 and ​https://github.com/macports/macports-ports/pull/3 are now in a single unified patchfile.

Closes: #69380

TESTED:
Tested on 10.4-10.5 ppc, 10.5-10.6 ppc (x86_64 Rosetta), 10.4-10.6
i386, 10.4-12.x x86_64, and 11.x-14.x arm64.
Now builds and passes at least some tests on all tested platforms,
except 10.4 ppc +universal.
Test behavior on 10.6+ is essentially unchanged. Tests on 10.4 and
10.5 have a few additional failures since v3.4.4 (the last version
that built successfully) due to new tests having been added.

[ballapete (Peter "Pete" Dyballa)]

There are still issues open because the patch file is faulty and makes all tests fail on PPC Leopard, Mac OS X 10.5.8, see attached files!

[ballapete (Peter "Pete" Dyballa)]

…/libffi/work/libffi-3.4.6/powerpc-apple-darwin9.8.0/testsuite/libffi.sum on PC Leopard, Mac OS X 10.5.8

[ballapete (Peter "Pete" Dyballa)]

…/libffi/work/libffi-3.4.6/powerpc-apple-darwin9.8.0/testsuite/libffi.log on PC Leopard, Mac OS X 10.5.8

[ballapete (Peter "Pete" Dyballa)]

On PPC Tiger, Mac OS X 10.4.11 lots of failing tests:

		=== libffi Summary ===

# of expected passes		840
# of unexpected failures	668
# of unresolved testcases	4
# of unsupported tests		30

[ballapete (Peter "Pete" Dyballa)]

On PPC Tiger I found that a LOG file has permissions of an executable:

/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/powerpc-apple-darwin8.11.0/testsuite:
  -rw-r--r--  1 macports admin   24885  5. Mär 22:51 Makefile
  -rwxr-xr-x  1 macports admin 2383914  5. Mär 23:17 libffi.log
  -rw-r--r--  1 macports admin  153623  5. Mär 23:17 libffi.sum
  -rw-r--r--  1 macports admin     896  5. Mär 22:51 site.exp

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Tiger, Mac OS X 10.4.11, testing libffi

[ballapete (Peter "Pete" Dyballa)]

Libffi.log from PPC Tiger, Mac OS X 10.4.11, from testsuite

[ballapete (Peter "Pete" Dyballa)]

Libffi.sum from PPC Tiger, Mac OS X 10.4.11, from testsuite

[fhgwright (Fred Wright)]

As I said previously (or at least I thought I did, but I'm not seeing my response), this is not the appropriate ticket for such issues. I just created #69454 for test failures.

Some one with access should reclose this ticket.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

The patches for #1 and #3 are now in a single unified patchfile.

Please be careful with your commit message syntax. On GitHub, # followed by a number refers to a GitHub pull request. Since it was not your intention to refer to GitHub pull requests 1 and 3 here, the use of the # symbol should have been avoided.