On Sat, 2020-04-04 at 00:01 +0100, Maciej W. Rozycki wrote: > Fix a problem with the libffi testsuite using a method to determine the > compiler to use resulting in the tool being different from one the > library has been built with, and causing a catastrophic failure from the > inability to actually choose any compiler at all in a cross-compilation > configuration. > > Address this problem by providing a DejaGNU configuration file defining > the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by > autoconf, which will have all the required options set for the target > compiler to build executables in the environment configured, removing > failures like: > > FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess > errors) > Excess errors: > default_target_compile: No compiler to compile with > UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation > failed to produce executable > > and bringing overall test results for the `riscv64-linux-gnu' target > (here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user > emulation mode as the target board) from: > > === libffi Summary === > > # of unexpected failures 708 > # of unresolved testcases 708 > # of unsupported tests 30 > > to: > > === libffi Summary === > > # of expected passes 1934 > # of unsupported tests 28 > > libffi/ > * configure.ac: Add testsuite/local.exp to output files. > * configure: Regenerate. > * testsuite/local.exp.in: New file. > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New > variable. > * testsuite/Makefile.in: Regenerate. Oh, I see it now. THe patches I ack'd were actually for upstream libffi.
You should actually wait for a libffi maintainer to ack those, not me :-) Sorry for the confusion. Both backports are OK once they're upstreamed. jeff >
