libffi @3.3_1 fails to build on 10.5 i386

[fhgwright (Fred Wright)]

The current libffi build fails on 10.5 i386, while working in all other cases I've tested, including 10.4 ppc/i386, and 10.5 ppc/x86_64. I suspect it has to do with the asm issues noted in the Portfile, with the -integrated-as option's not being available in this case. With all MacPorts compilers being blacklisted to avoid circular dependencies, and the Xcode compilers in older OS versions being gcc, -integrated-as isn't available. I was able to get it to build by forcing it to use the already installed clang-7.0, though that wouldn't work for building from scratch. Note that if it used the same sort of conditional blacklisting as in the libcxx port, this workaround would have been automatic.

Since the problem is alleged to relate to the as in old versions of cctools, perhaps using the MacPorts cctools would be a fix, but that would also have circular dependency problems (except with +xcode, but that would presumably defeat the purpose).

It appears that the only thing llvm uses libffi for is the external function interface, which I suspect isn't needed by clang. That suggests that a no-frills version of llvm, and a clang based on it, could build libffi without circularity. Splitting llvm into llvm-core and llvm-extras could take care of this, and perhaps some other questionable dependencies (ncurses and libedit, really?) as well.

This port is nomaintainer, but I'm CCing Ken as the last person to touch it.

[kencu (Ken)]

I see it built fine on 10.6 i386 using gcc-4.2 and the system assembler there.

This block of the Portfile should ensure that no macports-clang compiler is used to build it:

# Don't use macports gcc or clang toolchains to build this due to dependency cycles
compiler.blacklist-append macports-*

if {${os.platform} eq "darwin" && ${os.major} < 11} {
    # Doesn't actually use C++, and having the stdlib set to libc++
    # on 10.6 causes a macports-clang compiler to be chosen.
    configure.cxx_stdlib
}

Can you think of some reason that a clang compiler is being called in? That would appear to be what we need to fix on 10.5 i386 (which - AFAICT - should not be calling a clang compiler for this build in the first place).

[kencu (Ken)]

ie -- do you have your configure.compiler in your macports.conf set to a macports-clang-N compiler?

[fhgwright (Fred Wright)]

You misunderstood. The problem isn't that clang is being used by mistake; the problem (I think) is that it needs to use clang and can't, which is why I was able to bully it through by forcing a MacPorts clang on the command line.

I have no idea why the problem only shows up on 10.5/i386/Xcode3.1.4, but it does. I think this block is relevant:

# Older versions of cctools have a history of being problematic with complex
# asm like libffi has, so opt for the integrated assembler if it's available
if {[string match *clang* ${configure.compiler}]} {
    configure.cflags-append -integrated-as
}

Forcing it to use clang allows this to have an effect. It then rebuilds llvm, due to the dependency which is only "loosely circular".

I'll attach the logfile.

[fhgwright (Fred Wright)]

Build failure on 10.5 i386

[kencu (Ken)]

It should be building with gcc-4.2.

The error is that it is trying to build with clang, which it cannot do due to circular deps (and does not need to do).

We just need to figure out WHY it is trying to build with clang on your i386 Leopard system.

[kencu (Ken)]

OK -- it is trying to build with gcc-4.2 as it should, but it runs into this weirdness:

325	libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/opt/local/include -I. -I../include -Iinclude -I../src -pipe -Os -arch i386 -MT src/x86/sysv.lo -MD -MP -MF src/x86/.deps/sysv.Tpo -c ../src/x86/sysv.S  -fno-common -DPIC -o src/x86/.libs/sysv.o
326	../src/x86/sysv.S:808:section type does not match previous section type
327	../src/x86/sysv.S:809:FATAL:symbol: ___x86.get_pc_thunk.bx can't be a weak_definition (currently only supported in section of type coalesced)
328	make[3]: *** [src/x86/sysv.lo] Error 1
329	make[3]: *** Waiting for unfinished jobs....
330	libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/opt/local/include -pipe -Os -arch i386 -Wall -fexceptions -MT src/x86/ffi.lo -MD -MP -MF src/x86/.deps/ffi.Tpo -c ../src/x86/ffi.c -o src/x86/ffi.o >/dev/null 2>&1
331	make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_MacPro.local_ywg.ca.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.3/i386-apple-darwin9.8.0'

That is a strange one, I'll admit... I will have to see what is going on.

My first thought is that perhaps our modifications to cctools to force cctools as to use clang as the assembler if available might be responsible for this.

That only happens if there is a current version of clang installed. If you temporarily deactivate clang-5+ on i386 Leopard, does it build then?

If that does fix it, then we have a couple of #defines we can use to disable the clang assembler hack we put into cctools.

[kencu (Ken)]

Just to reassure you that it should not and does not require clang to build, here is libffi building on i386 10.6 using gcc-4.2 without any trouble <​https://build.macports.org/builders/ports-10.6_i386-builder/builds/17166/steps/install-port/logs/stdio> and you have also stated that you built it with i386 gcc-4.2 on Tiger.

[kencu (Ken)]

We may need to add -Wl,-no-pie to the linker flags.

<​https://stackoverflow.com/questions/50105581/how-do-i-get-rid-of-call-x86-get-pc-thunk-ax/50106310>

this is a common issue on i386 that I have come across many times before, but not with this exact error.

But I'm not certain how i386 Tiger and i386 Snow Leopard would build it, then...

[fhgwright (Fred Wright)]

Indeed I also built it successfully for 10.6 (and everything else), but that seemed less interesting to mention. :-) After your PPC fixes, 10.5 i386 was the only remaining failing case.

I did try deactivating the clangs, and it didn't help. I notice that the "preferred compilers" list doesn't care whether they're active, or even installed (presumably so that it can install or activate if needed).

Would the -no-pie break things in cases where PIC is actually wanted?

[kencu (Ken)]

Help appreciated. I'm bringing my 10.5 leopard intel system back up to date, but as you know, that can take some time :>

I suppose the next thing I might consider trying is some version of this (from memory, maybe a typo in here):

configure.cflags-append -fno-pie
configure.ldflags-append -Wl,-no-pie

[kencu (Ken)]

I think if you have -no-pie it just gives the OS less latitude in where it can put the objects, but doesn't seem to break anything that I've seen so far...

[kencu (Ken)]

this one is being very stubborn. So far I cannot find the right chord of options to pass to the toolchain to make it all happy. The build really assumes that PIC will work on darwin, and it's not easy to knock it off that assumption. Perhaps seeing how the i386 version built on Tiger would give some insight.

I have this much in the Portfile:

configure.env-append lt_cv_prog_compiler_pic_works=no
configure.env-append lt_cv_prog_compiler_pic_works_CXX=no
configure.env-append lt_cv_prog_compiler_pic=
configure.env-append lt_cv_prog_compiler_pic_CXX=
configure.args-append --without-pic
configure.cflags-append -mdynamic-no-pic
configure.ldflags-append -Wl,-read_only_relocs,suppress

and it gets to the final link and fails

libtool: link: /usr/bin/gcc-4.2 -dynamiclib  -o .libs/libffi.7.dylib  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o    -L/opt/bootstrap/lib  -Os -mdynamic-no-pic -arch i386 -Wl,-headerpad_max_install_names -Wl,-read_only_relocs -Wl,suppress -arch i386 -Wl,-headerpad_max_install_names -Wl,-read_only_relocs -Wl,suppress -arch i386   -install_name  /opt/bootstrap/lib/libffi.7.dylib -compatibility_version 9 -current_version 9.0 -Wl,-single_module
ld: in src/x86/.libs/sysv.o, in section __TEXT,__eh_frame reloc 0: bad length for GENERIC_RELOC_SECTDIFF
collect2: ld returned 1 exit status

[kencu (Ken)]

that error appears to be coming because of this bit <​https://opensource.apple.com/source/ld64/ld64-85.2.1/src/MachOReaderRelocatable.hpp.auto.html>

			case GENERIC_RELOC_SECTDIFF:
			case GENERIC_RELOC_LOCAL_SECTDIFF:
				{
					if ( !nextRelocIsPair ) {
						warning("GENERIC_RELOC_SECTDIFF missing following pair");
						break;
					}
					x86::ReferenceKinds kind = x86::kPointerDiff;
					uint32_t contentAddr = 0;
					switch ( sreloc->r_length() ) {
						case 0:
						case 3:
							throw "bad length for GENERIC_RELOC_SECTDIFF";
						case 1:
							kind = x86::kPointerDiff16;
							contentAddr = LittleEndian::get16(*((uint16_t*)fixUpPtr));
							break;
						case 2:
							kind = x86::kPointerDiff;
							contentAddr = LittleEndian::get32(*fixUpPtr);
							break;
					}

[fhgwright (Fred Wright)]

Build success on 10.4 i386

[fhgwright (Fred Wright)]

Build success on 10.5 ppc

[fhgwright (Fred Wright)]

Build success on 10.5 x86_64

[fhgwright (Fred Wright)]

Since that's just trading one problem for another, maybe it's the wrong rabbit hole to be going down.

I'm attaching logfiles from three "neighboring" success cases - 10.4 i386, 10.5 ppc, 10.5 x86_64. I think you already have 10.6.

On the whole PIC/PIE thing:

AIUI, fully position-independent code, as needed in shared libraries or code to be statically linked into shared libraries, needs -fPIC, which is stronger than -fPIE. For code only intended for executables, including statically linking into executables, -fPIE is sufficient, and serves entirely just to support ASLR. I think it tracks this to determine whether ASLR is usable on a given executable. OSX added ASLR support in 10.5, so -fPIE is pointless for 10.4. It's not clear in all this mess whether -fPIC is present, which would be needed for shared libraries.

[kencu (Ken)]

On i386 Tiger, we see warnings at the same file, but not errors:

355	../src/x86/sysv.S:808:section type does not match previous section type
356	../src/x86/sysv.S:814:section type does not match previous section type

I did manage to get past that spot in Leopard i386 with a small edit to the sysv.S source file:

- .section __TEXT,__text,coalesced,pure_instructions;
+ .section __TEXT,__textcoal_nt,coalesced,pure_instructions;

but then still ran into the same linker error in the end:

ld: in src/x86/.libs/sysv.o, in section __TEXT,__eh_frame reloc 0: bad length for GENERIC_RELOC_SECTDIFF

working on it...

It is well known, as you point out, that the libffi assembler needs are advanced in nature, and no doubt the 32bit darwin part of it suffers more than most. We are trying to see if we can tweak it to build with the system toolchain, as otherwise our bootstrapping is complicated.

We could consider salting away libffi 3.2.1 in a directory and building some llvm version against it (3.7?) that gets us to a current libffi version. But I'm hoping we don't have to do that as it just adds ever more complexity to supporting and bootstrapping these older systems that I would like to avoid.

[fhgwright (Fred Wright)]

I reran the builds with buildmakejobs=1 for easier diffing, but I won't bother uploading them if you don't need them.

It is well known, as you point out, that the libffi assembler needs are advanced in nature, and no doubt the 32bit darwin part of it suffers more than most. We are trying to see if we can tweak it to build with the system toolchain, as otherwise our bootstrapping is complicated.

Indeed.

We could consider salting away libffi 3.2.1 in a directory and building some llvm version against it (3.7?) that gets us to a current libffi version. But I'm hoping we don't have to do that as it just adds ever more complexity to supporting and bootstrapping these older systems that I would like to avoid.

That would indeed be pretty ugly.

The approach I suggested of splitting llvm would be a fairly clean approach (assuming clang doesn't need the external function interface), but it would be a nontrivial amount of work. With the circular dependency gone, libffi could blacklist gcc* and unconditionally use -integrated-as. That would be no change on later OS versions where Xcode supplies clang, but it would use a MacPorts clang on the earlier versions.

In general, keeping compiler dependencies to an absolute minimum is good to avoid the circular dependency issues, and maximize the compiler choices for building something.

There's a somewhat similar problem with libcxx, aggravated by the fact that it defaults to +universal. When starting from scratch on 10.4 or 10.5 i386, the default +universal adds ppc, which blacklists older clang versions, while newer clang versions are blacklisted to avoid circular dependencies (unless already installed), leaving only gcc, which can't build libcxx. One needs to manually install libcxx -universal to make it work.

[kencu (Ken)]

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++)

[kencu (Ken)]

I think this commit is relevant, but reverting it did not fix the build on i386 Leopard using the default system toolchain.

<​https://github.com/libffi/libffi/commit/65da63abc843fe448aaa86015d094cf016f325ba#diff-0647bc06aa7b474693cfc8a5d4cec85d>

[kencu (Ken)]

Well, one way to fix it is to disable the eh_frame unwinding that was added. That does actually fairly well on the test suite, but obviously won't unwind. That is likely not a big issue for Leopard at this point in time. (I believe 3.2.1 didn't unwind either, as the code to do that appears to have been added after 3.2.1 was released):

		=== 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 ...
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O2 execution test
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O0 execution test
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O2 execution test
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O0 execution test
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O2 execution test
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		539
# of unexpected failures	5
# of unsupported tests		206

[kencu (Ken)]

allows libffi 3.3 testsuite to build with gcc-4.2

[kencu (Ken)]

building this on Leopard i386 using clang-3.4 pulls in a lot of interesting assembly errors in the area of concern, but it does finish

ibtool: link: /opt/local/bin/clang-mp-3.4 -dynamiclib  -o .libs/libffi.7.dylib  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o   -L/opt/local/lib  -Os -arch i386 -Wl,-headerpad_max_install_names -arch i386 -Wl,-headerpad_max_install_names -arch i386   -install_name  /opt/local/lib/libffi.7.dylib -compatibility_version 9 -current_version 9.0 -Wl,-single_module
ld: warning: could not create compact unwind for _ffi_call_i386: non-standard register 5 being saved in prolog
ld: warning: could not create compact unwind for _ffi_go_closure_EAX: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_go_closure_ECX: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_i386: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_go_closure_STDCALL: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_REGISTER: register saved more than once (might be shrink wrap)
ld: warning: could not create compact unwind for _ffi_closure_STDCALL: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_raw_SYSV: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_raw_THISCALL: register saved more than once (might be shrink wrap)
libtool: link: (cd ".libs" && rm -f "libffi.dylib" && ln -s "libffi.7.dylib" "libffi.dylib")
libtool: link: ar cru .libs/libffi.a  src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/sysv.o
libtool: link: ranlib .libs/libffi.a

it looks like all the eh_unwind functions are being skipped anyway in this build by the linker...

[kencu (Ken)]

clang-3.7 does no better (Leopard i386):

libtool: link: /opt/local/bin/clang-mp-3.7 -dynamiclib  -o .libs/libffi.7.dylib  src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o   -L/opt/local/lib  -Os -arch i386 -Wl,-headerpad_max_install_names -arch i386 -Wl,-headerpad_max_install_names -arch i386   -install_name  /opt/local/lib/libffi.7.dylib -compatibility_version 9 -current_version 9.0 -Wl,-single_module
ld: warning: could not create compact unwind for _ffi_call_i386: non-standard register 5 being saved in prolog
ld: warning: could not create compact unwind for _ffi_go_closure_EAX: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_go_closure_ECX: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_i386: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_go_closure_STDCALL: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_REGISTER: register saved more than once (might be shrink wrap)
ld: warning: could not create compact unwind for _ffi_closure_STDCALL: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_raw_SYSV: does not use EBP or ESP based frame
ld: warning: could not create compact unwind for _ffi_closure_raw_THISCALL: register saved more than once (might be shrink wrap)
libtool: link: (cd ".libs" && rm -f "libffi.dylib" && ln -s "libffi.7.dylib" "libffi.dylib")

[kencu (Ken)]

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

[fhgwright (Fred Wright)]

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.

[kencu (Ken)]

Replying to kencu:

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

Sadly, no. The system ld64 on Leopard is too old to understand that flag, and throws an error.

There is apparently some way to write into the asm that you don't want compact unwind, but my asm-fu is not strong, grasshopper.

[kencu (Ken)]

libffi 3.3 does build on 10.4 i386 using gcc-4.2, but it fails the testsuite quite badly.

[kencu (Ken)]

For anyone interested, currently I have just pegged back libffi to version 3.2 on Tiger and Leopard Intel versions until / if someone feels like fixing the assembly in libffi.... no small project.

Because I sometimes cross-compile, and because libffi 3.3 offers no detectable advantage over libffi 3.2 on PowerPC that I can see, I also pegged libffi to 3.2 on those systems as well in my own repos.

It is possible that is what we might wind up doing in the libffi Portfile in the end (bumping the epoch and pegging < 10.6 at libffi version 3.2).

[kencu (Ken)]

well I guess it does build on i386 Tiger, although has issues as noted.

[kencu (Ken)]

In cca235463eab122aa94b3091f77d41e2ad7db582/macports-ports (master):

libffi: fix build on Intel < darwin11

closes: #61170

no revbump - hasn't been building on intel darwin < 11
no changes relevant to installions on ppc darwin < 11

[fhgwright (Fred Wright)]

Actually, the build failure was just the tip of the iceberg. I've been digging into this quite a bit, and the only cases with no known issues are 10.7+ non-universal.

A few notes:

The compact-unwind warnings are just a harmless red herring, and are already happening on 10.7. The source code doesn't create compact unwind - it creates DWARF unwind, which is then translated by a sufficiently recent linker into compact unwind in order to save space. According to the Apple documentation, this began with 10.6. I'm not sure whether there's any actual OS involvement, or whether "10.6" is just a proxy for "Xcode 3.2", but in any case, the reason the 10.5 linker doesn't support the -no_compact_unwind option is that it has no knowledge of compact unwind at all.

Using the integrated assembler never helps, and actually hurts on 10.6 if building with clang (which is desirable for some reasons), since the Xcode 3.2 clang assembler is missing some needed x86_64 instructions. I don't think it's worth the effort to figure out when, if ever, -integrated-as was actually useful.

I came up with a fix for sysv.S that's actually a code improvement with a side effect of getting rid of the bug-tickling .section directive altogether. With this change, it assembles successfully but runs afoul of the "bad length for GENERIC_RELOC_SECTDIFF" issue. That seems to be a linker bug, since the object file is identical between the working and non-working cases, with only the linker being different. Unfortunately, no Xcode 3.1 compiler choice avoids this linker bug (probably the same linker). I was able to fix it for test purposes by rudely forcing the Xcode gcc 4.2 to use the MacPorts ld64, but that's not a viable approach for real.

Building with apple-gcc42 is a possible solution, but that also doesn't currently build on 10.5 i386. It's also one of many gcc versions that produces bad assembly code for certain x86_64 floating-point cases, though I have a fix for that.

You don't say how you got past the "bad length for GENERIC_RELOC_SECTDIFF" problem. And note that using __textcoal_nt is a step backwards, since there are deprecation warnings about it.

Aside from all that, the tests have issues both with the test framework and with actual bugs in libffi, some of which I've fixed here and some of which I haven't. I hadn't planned on submitting a PR until I'd finished sorting it all out.

[kencu (Ken)]

I would have just rolled back to libffi-3.2.1 and left it there forever, but MacPorts wouldn't like that.

The sysV.S fix I did essentially restores the 3.2.1 behaviour, changing back to the asm it had before, and disabling the new additions that don't compile.

Let's take you fixes upstream like I did with the darwin PowerPC fixes (now committed upstream) and see if we can sell them there, once you get them into a marketable shape.

[ballapete (Peter "Pete" Dyballa)]

Around Christmas 2022 the original source of src/x86/sysv.S was patched, see ​here. This is the reason why patch file patch-libffi-intel-leopard-sysv.diff partly fails:

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

I am trying to omit these lines from the original patch and am going to see whether libffi 3.4.6 will build on PPC Tiger, Mac OS X 10.4.11…

[ballapete (Peter "Pete" Dyballa)]

The whole patch file patch-libffi-intel-leopard-sysv.diff can be omitted now, libffi-3.4.6 builds, but complains a few times:

Makefile:2123: no file name for `-include'

port -vs test libffi seems to have problems on PPC Tiger, Mac OS X 10.4.11:

WARNING: Couldn't find the global config file.
Using ../../testsuite/lib/libffi.exp as tool init file.
Test run by root on Tue Feb 20 15:07:43 2024
Native configuration is powerpc-apple-darwin8.11.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 ...
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=1 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O0 (test for excess errors)
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=1 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O2 (test for excess errors)
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=2 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O0 (test for excess errors)
FAIL: libffi.bhaible/test-call.c -W -Wall -DDGTEST=2 -Wno-unused-variable -Wno-unused-parameter -Wno-uninitialized -O2 (test for excess errors)

The FAILures continue…

[ballapete (Peter "Pete" Dyballa)]

Finished with:

		=== libffi Summary ===

# of expected passes		840
# of unexpected failures	668
# of unresolved testcases	4
# of unsupported tests		30
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_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6" && /usr/bin/make check 

[ballapete (Peter "Pete" Dyballa)]

On PPC Leopard, Mac OS X 10.5.8, the same behaviour with failing patch and building when the patch was removed. port -vs test libffi produces failures:

		=== libffi Summary ===

# of unexpected failures	298
# of unresolved testcases	298
# of unsupported tests		209
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_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6" && /usr/bin/make check 
Exit code: 2

[fhgwright (Fred Wright)]

AFAIK, libffi has never passed all of its tests on any OS version, so don't sweat that too much.

[kencu (Ken)]

here's what we get on a current arm64 system:

		=== libffi Summary ===

# of expected passes		1620
# of unexpected failures	6
# of unsupported tests		2

the 6 failures seem to be in the go bindings, but I can't see the solution immediately to those. Something to do with a missing define, I think.

[kencu (Ken)]

and looks like the last time I fixed it for i386 Leopard, there were 5 unexpected failures.

So having hundreds and hundreds of test failures is indeed pretty awful.

[ryandesign (Ryan Carsten Schmidt)]

This ticket was resolved and closed three years ago. New issues should go in new tickets. This new issue has been filed as #69380 and discussion should continue there.