* libffi 3.3 release candidate 1 @ 2019-10-24 11:17 Anthony Green 2019-10-25 10:08 ` Matthias Klose ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Anthony Green @ 2019-10-24 11:17 UTC (permalink / raw) To: libffi-discuss libffi 3.3 release candidate 1 is available for testing... https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz https://github.com/libffi/libffi/releases/tag/v3.3-rc1 AG ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-24 11:17 libffi 3.3 release candidate 1 Anthony Green @ 2019-10-25 10:08 ` Matthias Klose 2019-10-25 10:29 ` John Paul Adrian Glaubitz ` (2 more replies) 2019-11-08 9:21 ` Matthias Klose 2019-11-27 7:54 ` Matthias Klose 2 siblings, 3 replies; 25+ messages in thread From: Matthias Klose @ 2019-10-25 10:08 UTC (permalink / raw) To: Anthony Green, libffi-discuss; +Cc: Debian m68k, debian-superh On 24.10.19 13:16, Anthony Green wrote: > libffi 3.3 release candidate 1 is available for testing... > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 test results from https://buildd.debian.org/status/package.php?p=libffi&suite=experimental without test failures: amd64, armel, armhf, arm64, mips64el, mipsel, ppc64el, s390x, alpha, hppa, ia64, kfreebsd-amd64, powerpc. ppc64, riscv64, sparc64, x32 I didn't look at XPASSes. i386 (i686-linux-gnu), hurd-i386, kfreebsd-i386: Running ../../testsuite/libffi.bhaible/bhaible.exp ... FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=53 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__ execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=53 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__ execution test m68k: Running ../../testsuite/libffi.bhaible/bhaible.exp ... FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test sh4: Running ../../testsuite/libffi.bhaible/bhaible.exp ... FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 10:08 ` Matthias Klose @ 2019-10-25 10:29 ` John Paul Adrian Glaubitz 2019-10-25 14:41 ` Andreas Schwab 2019-10-26 11:35 ` Anthony Green 2019-10-26 12:54 ` Anthony Green 2 siblings, 1 reply; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-25 10:29 UTC (permalink / raw) To: Matthias Klose, Anthony Green, libffi-discuss; +Cc: Debian m68k, debian-superh On 10/25/19 12:08 PM, Matthias Klose wrote: > On 24.10.19 13:16, Anthony Green wrote: >> libffi 3.3 release candidate 1 is available for testing... >> >> https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz >> https://github.com/libffi/libffi/releases/tag/v3.3-rc1 > > test results from > https://buildd.debian.org/status/package.php?p=libffi&suite=experimental > > m68k: > Running ../../testsuite/libffi.bhaible/bhaible.exp ... > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > > sh4: > Running ../../testsuite/libffi.bhaible/bhaible.exp ... > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test It makes little sense to run these tests on qemu. If you want me to run the testsuite, I can do it on real hardware. For the package, please make sure the package respects the "nocheck" flag. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 10:29 ` John Paul Adrian Glaubitz @ 2019-10-25 14:41 ` Andreas Schwab 2019-10-25 14:44 ` John Paul Adrian Glaubitz 0 siblings, 1 reply; 25+ messages in thread From: Andreas Schwab @ 2019-10-25 14:41 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On Okt 25 2019, John Paul Adrian Glaubitz wrote: > It makes little sense to run these tests on qemu. If qemu cannot run these tests it is broken. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 14:41 ` Andreas Schwab @ 2019-10-25 14:44 ` John Paul Adrian Glaubitz 2019-10-25 18:32 ` Andreas Schwab 0 siblings, 1 reply; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-25 14:44 UTC (permalink / raw) To: Andreas Schwab Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On 10/25/19 4:41 PM, Andreas Schwab wrote: > On Okt 25 2019, John Paul Adrian Glaubitz wrote: > >> It makes little sense to run these tests on qemu. > > If qemu cannot run these tests it is broken. It's qemu-user that we are using here, not qemu-system. qemu-user is more finicky when it comes to running testsuites. I'm planning to switch to qemu-system in the future, but qemu-system is currently memory-limited meaning we couldn't build things like GHC. And the Amiga Vampire boards don't support an MMU yet to run Linux. Once they'll do that in the future, they might be a viable option. Aranym is too slow to be able to catch up with the rest of Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 14:44 ` John Paul Adrian Glaubitz @ 2019-10-25 18:32 ` Andreas Schwab 2019-10-25 18:37 ` John Paul Adrian Glaubitz 0 siblings, 1 reply; 25+ messages in thread From: Andreas Schwab @ 2019-10-25 18:32 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On Okt 25 2019, John Paul Adrian Glaubitz wrote: > On 10/25/19 4:41 PM, Andreas Schwab wrote: >> On Okt 25 2019, John Paul Adrian Glaubitz wrote: >> >>> It makes little sense to run these tests on qemu. >> >> If qemu cannot run these tests it is broken. > > It's qemu-user that we are using here, not qemu-system. qemu-user is more finicky > when it comes to running testsuites. There is nothing finicky about this testsuite. It's pure user-space. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 18:32 ` Andreas Schwab @ 2019-10-25 18:37 ` John Paul Adrian Glaubitz 2019-10-25 19:04 ` Andreas Schwab 0 siblings, 1 reply; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-25 18:37 UTC (permalink / raw) To: Andreas Schwab Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On 10/25/19 8:32 PM, Andreas Schwab wrote: > On Okt 25 2019, John Paul Adrian Glaubitz wrote: >> It's qemu-user that we are using here, not qemu-system. qemu-user is more finicky >> when it comes to running testsuites. > > There is nothing finicky about this testsuite. It's pure user-space. Yes, but qemu-user has known bugs which is why I disable testsuites for the time being and I have elaborated why Aranym or real hardware are not an option at the moment either I'm always open if someone offers a better solution to our current setup though but currently that's just how things are. If someone needs tests on real hardware, I can perform these tomorrow, both on sh4 and m68k. PS: I think that converting the m68k backend in GCC from CC0 to MODE is a more pressing problem at the moment. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 18:37 ` John Paul Adrian Glaubitz @ 2019-10-25 19:04 ` Andreas Schwab 2019-10-25 19:07 ` John Paul Adrian Glaubitz 0 siblings, 1 reply; 25+ messages in thread From: Andreas Schwab @ 2019-10-25 19:04 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On Okt 25 2019, John Paul Adrian Glaubitz wrote: > On 10/25/19 8:32 PM, Andreas Schwab wrote: >> On Okt 25 2019, John Paul Adrian Glaubitz wrote: >>> It's qemu-user that we are using here, not qemu-system. qemu-user is more finicky >>> when it comes to running testsuites. >> >> There is nothing finicky about this testsuite. It's pure user-space. > > Yes, but qemu-user has known bugs If it cannot even get the user-space ABI right it is useless. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 19:04 ` Andreas Schwab @ 2019-10-25 19:07 ` John Paul Adrian Glaubitz 0 siblings, 0 replies; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-25 19:07 UTC (permalink / raw) To: Andreas Schwab Cc: Matthias Klose, Anthony Green, libffi-discuss, Debian m68k, debian-superh On 10/25/19 9:04 PM, Andreas Schwab wrote: > On Okt 25 2019, John Paul Adrian Glaubitz wrote: > >> On 10/25/19 8:32 PM, Andreas Schwab wrote: >>> On Okt 25 2019, John Paul Adrian Glaubitz wrote: >>>> It's qemu-user that we are using here, not qemu-system. qemu-user is more finicky >>>> when it comes to running testsuites. >>> >>> There is nothing finicky about this testsuite. It's pure user-space. >> >> Yes, but qemu-user has known bugs > > If it cannot even get the user-space ABI right it is useless. It works for me and it produces a Debian/m68k distribution that a lot of people are using on emulators and real 68k hardware without any problems, including my one of my own Amigas. So I wouldn't say it's useless. I also haven't looked at this particular issue now, so I don't know what the problem is. Might just be an artifact. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 10:08 ` Matthias Klose 2019-10-25 10:29 ` John Paul Adrian Glaubitz @ 2019-10-26 11:35 ` Anthony Green 2019-10-26 12:54 ` Anthony Green 2 siblings, 0 replies; 25+ messages in thread From: Anthony Green @ 2019-10-26 11:35 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss, Debian m68k, debian-superh On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <doko@ubuntu.com> wrote: > test results from > https://buildd.debian.org/status/package.php?p=libffi&suite=experimental Thank you, Matthias! i386 (i686-linux-gnu), hurd-i386, kfreebsd-i386: > > Running ../../testsuite/libffi.bhaible/bhaible.exp ... > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=53 > -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable > -Wno-uninitialized -O2 -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__ > execution test > FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=53 > -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable > -Wno-uninitialized -O2 -fomit-frame-pointer -DABI_NUM=FFI_STDCALL > -DABI_ATTR=__STDCALL__ execution test > > There's a pending stdcall patch. I wanted to research more, as I seem to recall something about Microsoft/GCC incompatibility on this front. As for m68k, or sh4 -- let me check the test cases carefully, but I don't plan on fixing either of those platforms myself. There's a known problem with the riscv port, in that it doesn't promote results to the natural word size - but we don't have a test case for this in the suite. So my plan is to add a test case for this, possibly commit the stdcall patch, and make release candidate 2. AG > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-25 10:08 ` Matthias Klose 2019-10-25 10:29 ` John Paul Adrian Glaubitz 2019-10-26 11:35 ` Anthony Green @ 2019-10-26 12:54 ` Anthony Green 2019-10-31 19:49 ` Anthony Green 2 siblings, 1 reply; 25+ messages in thread From: Anthony Green @ 2019-10-26 12:54 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss, Debian m68k, debian-superh On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <doko@ubuntu.com> wrote:On 24.10.19 13:16, Anthony Green wrote: > > libffi 3.3 release candidate 1 is available for testing... > > > > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 > > test results from > https://buildd.debian.org/status/package.php?p=libffi&suite=experimental > > without test failures: amd64, armel, armhf, arm64, mips64el, mipsel, > ppc64el, > s390x, alpha, hppa, ia64, kfreebsd-amd64, powerpc. ppc64, riscv64, > sparc64, x32 > > I didn't look at XPASSes. > The XPASSes are related to an ABI incompatibility problem in GCC that has since been fixed. AG ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-26 12:54 ` Anthony Green @ 2019-10-31 19:49 ` Anthony Green 2019-10-31 20:32 ` John Paul Adrian Glaubitz 0 siblings, 1 reply; 25+ messages in thread From: Anthony Green @ 2019-10-31 19:49 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss, Debian m68k, debian-superh I've figured out a way to use the GCC compile farm ( https://cfarm.tetaneutral.net/) with travis-ci so real hardware builds/tests can participate in the travis-ci testing process. The trick was to write a web service (https://github.com/libffi/cfarm-test-libffi) that travis-ci will curl to for specific platforms, and it is responsible for ssh'ing into the appropriate compile farm box for testing. It seems to work well, so I've replaced the aarch64 qemu testing with real aarch64, as well as added ppc64le and mips64el linux tests. Here's some sample results: https://travis-ci.org/libffi/libffi/builds/605684679 If anybody is willing to give me ssh access to additional gear, I'd be happy to add them to the mix. AG On Sat, Oct 26, 2019 at 8:53 AM Anthony Green <green@moxielogic.com> wrote: > On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <doko@ubuntu.com> wrote:On > 24.10.19 13:16, Anthony Green wrote: > >> > libffi 3.3 release candidate 1 is available for testing... >> > >> > >> https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz >> > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 >> >> test results from >> https://buildd.debian.org/status/package.php?p=libffi&suite=experimental >> >> without test failures: amd64, armel, armhf, arm64, mips64el, mipsel, >> ppc64el, >> s390x, alpha, hppa, ia64, kfreebsd-amd64, powerpc. ppc64, riscv64, >> sparc64, x32 >> >> I didn't look at XPASSes. >> > > The XPASSes are related to an ABI incompatibility problem in GCC that has > since been fixed. > > AG > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-31 19:49 ` Anthony Green @ 2019-10-31 20:32 ` John Paul Adrian Glaubitz [not found] ` <CAAs=koj3HU08uxx36809NcPYe33xvEjUDsLwJc_9R8V4tbr9Zg@mail.gmail.com> 0 siblings, 1 reply; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-31 20:32 UTC (permalink / raw) To: Anthony Green; +Cc: Matthias Klose, libffi-discuss, Debian m68k, debian-superh Hi Anthony! > On Oct 31, 2019, at 9:06 PM, Anthony Green <green@moxielogic.com> wrote: > > > I've figured out a way to use the GCC compile farm (https://cfarm.tetaneutral.net/) with travis-ci so real hardware builds/tests can participate in the travis-ci testing process. (...) > If anybody is willing to give me ssh access to additional gear, I'd be happy to add them to the mix. The GCC compile farm also includes a SPARC T5 LDOM which runs Debian unstable which we set up. You should be able to use that as well. Although I’m not so sure if it’s okay to run CI tests on the compile farm for every commit as the resources are limited. Adrian ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <CAAs=koj3HU08uxx36809NcPYe33xvEjUDsLwJc_9R8V4tbr9Zg@mail.gmail.com>]
* Re: libffi 3.3 release candidate 1 [not found] ` <CAAs=koj3HU08uxx36809NcPYe33xvEjUDsLwJc_9R8V4tbr9Zg@mail.gmail.com> @ 2019-10-31 22:16 ` John Paul Adrian Glaubitz 2019-11-01 8:01 ` John Paul Adrian Glaubitz 1 sibling, 0 replies; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-10-31 22:16 UTC (permalink / raw) To: Anthony Green Cc: Anthony Green, Matthias Klose, libffi-discuss, Debian m68k, debian-superh Hi! On 10/31/19 9:47 PM, Anthony Green wrote: > I was using that one, but I haven't been able to connect to it > today, so I took it out for now. I'll try again later. The machine is up and reachable: glaubitz@zlogin2:~> ssh gcc202.fsffrance.org Linux gcc202 4.19.0-5-sparc64-smp #1 SMP Debian 4.19.37-6 (2019-07-18) sparc64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Oct 31 19:05:52 2019 from XXX.XXX.XXX.XXX glaubitz@gcc202:~$ But there are certain hosts from which access doesn't work. I think Anatoly Pugachev who set up the LDOM can probably figure out what's wrong. > libffi doesn't see a ton of activity, so I predict a light load... > but this an experiment and we'll see how it goes! For m68k, qemu-system-m68k can be used these days to set up a Debian/m68k system [1]. Adding one of my SuperH (sh4) systems to the GCC compile farm is also on my TODO list but I just don't have the time at the moment :(. FWIW, if you need access to a certain architecture, please let me know. Adrian > [1] https://wiki.debian.org/M68k/QemuSystemM68k -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 [not found] ` <CAAs=koj3HU08uxx36809NcPYe33xvEjUDsLwJc_9R8V4tbr9Zg@mail.gmail.com> 2019-10-31 22:16 ` John Paul Adrian Glaubitz @ 2019-11-01 8:01 ` John Paul Adrian Glaubitz 2019-11-01 22:24 ` John Paul Adrian Glaubitz 1 sibling, 1 reply; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-01 8:01 UTC (permalink / raw) To: Anthony Green Cc: Anthony Green, Matthias Klose, libffi-discuss, Debian m68k, debian-superh [-- Attachment #1: Type: text/plain, Size: 470 bytes --] Hi! Here's the log for running the testsuite on sh4 with kernel 3.16 and glibc 2.29, gcc-9 on real hardware (my SH7785LCR evaluation board). m68k is coming later. It was invoked with: $ ./configure && make -j2 && make check | tee ~/ffi-sh4.log Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 [-- Attachment #2: ffi-sh4.log --] [-- Type: text/x-log, Size: 5365 bytes --] MAKE sh4a-unknown-linux-gnu : 0 * check make[1]: Entering directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu' Making check in include make[2]: Entering directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/include' make[2]: Nothing to be done for 'check'. make[2]: Leaving directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/include' Making check in testsuite make[2]: Entering directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/testsuite' make check-DEJAGNU make[3]: Entering directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/testsuite' Making a new site.exp file ... srcdir='../../testsuite'; export srcdir; \ EXPECT=expect; export EXPECT; \ if /bin/bash -c "runtest --version" > /dev/null 2>&1; then \ exit_status=0; l='libffi'; for tool in $l; do \ if runtest --tool $tool --srcdir $srcdir ; \ then :; else exit_status=1; fi; \ done; \ else echo "WARNING: could not find 'runtest'" 1>&2; :;\ fi; \ exit $exit_status Using ../../testsuite/lib/libffi.exp as tool init file. Test run by glaubitz on Fri Nov 1 00:16:22 2019 Native configuration is sh4a-unknown-linux-gnu === libffi tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/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 -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test Running ../../testsuite/libffi.call/call.exp ... Running ../../testsuite/libffi.complex/complex.exp ... Running ../../testsuite/libffi.go/go.exp ... === libffi Summary === # of expected passes 2133 # of unexpected failures 18 # of unsupported tests 30 make[3]: Leaving directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/testsuite' make[2]: Leaving directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu/testsuite' make[1]: Leaving directory '/home/glaubitz/libffi-3.3-rc1/sh4a-unknown-linux-gnu' ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-01 8:01 ` John Paul Adrian Glaubitz @ 2019-11-01 22:24 ` John Paul Adrian Glaubitz 0 siblings, 0 replies; 25+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-01 22:24 UTC (permalink / raw) To: Anthony Green Cc: Anthony Green, Matthias Klose, libffi-discuss, Debian m68k, debian-superh [-- Attachment #1: Type: text/plain, Size: 623 bytes --] Hello! On 11/1/19 9:01 AM, John Paul Adrian Glaubitz wrote: > Here's the log for running the testsuite on sh4 with kernel 3.16 and glibc 2.29, > gcc-9 on real hardware (my SH7785LCR evaluation board). m68k is coming later. Attaching the testsuite run for libffi 3.3-rc1 on my Amiga 4000/68060 running Debian unstable with kernel 5.3.0 and glibc 2.29. Let me know if you need any more information. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 [-- Attachment #2: ffi-m68k.log --] [-- Type: text/x-log, Size: 4006 bytes --] MAKE m68k-unknown-linux-gnu : 0 * check make[1]: Entering directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu' Making check in include make[2]: Entering directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/include' make[2]: Nothing to be done for 'check'. make[2]: Leaving directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/include' Making check in testsuite make[2]: Entering directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/testsuite' make check-DEJAGNU make[3]: Entering directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/testsuite' Making a new site.exp file ... srcdir='../../testsuite'; export srcdir; \ EXPECT=expect; export EXPECT; \ if /bin/bash -c "runtest --version" > /dev/null 2>&1; then \ exit_status=0; l='libffi'; for tool in $l; do \ if runtest --tool $tool --srcdir $srcdir ; \ then :; else exit_status=1; fi; \ done; \ else echo "WARNING: could not find 'runtest'" 1>&2; :;\ fi; \ exit $exit_status Using ../../testsuite/lib/libffi.exp as tool init file. Test run by root on Fri Nov 1 00:31:40 2019 Native configuration is m68k-unknown-linux-gnu === libffi tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/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 -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=57 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 execution test FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O2 -fomit-frame-pointer execution test Running ../../testsuite/libffi.call/call.exp ... Running ../../testsuite/libffi.complex/complex.exp ... Running ../../testsuite/libffi.go/go.exp ... === libffi Summary === # of expected passes 2140 # of unexpected failures 11 # of unsupported tests 30 make[3]: Leaving directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/testsuite' make[2]: Leaving directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu/testsuite' make[1]: Leaving directory '/srv/libffi-3.3-rc1/m68k-unknown-linux-gnu' ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-24 11:17 libffi 3.3 release candidate 1 Anthony Green 2019-10-25 10:08 ` Matthias Klose @ 2019-11-08 9:21 ` Matthias Klose 2019-11-08 14:28 ` Anthony Green 2019-11-27 7:54 ` Matthias Klose 2 siblings, 1 reply; 25+ messages in thread From: Matthias Klose @ 2019-11-08 9:21 UTC (permalink / raw) To: libffi-discuss On 24.10.19 13:16, Anthony Green wrote: > libffi 3.3 release candidate 1 is available for testing... > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 started doing some test rebuilds using this version in https://launchpad.net/~doko/+archive/ubuntu/libffi/+packages and re-running failed builds against 3.2.1 in https://launchpad.net/~doko/+archive/ubuntu/libffi-3.2.1/+packages Regressions are seen with ecl: amd64, i386 gwrap: arm64 gauche-c-wrapper: arm64 jffi: all architectures polyml: amd64, i386 python-cffi: arm64 ruby-ffi: arm64 (but ruby2.5 ftbfs for unrelated reasons) I'm following up with more rebuilds. Matthias ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-08 9:21 ` Matthias Klose @ 2019-11-08 14:28 ` Anthony Green 2019-11-09 16:04 ` Matthias Klose 2019-11-26 8:39 ` Matthias Klose 0 siblings, 2 replies; 25+ messages in thread From: Anthony Green @ 2019-11-08 14:28 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss Thanks, Matthias, this is incredibly helpful. For ecl, it looks like they are using FFI_UNIX64 on the 32-bit x86, and similar for amd64. This is easy to fix, and I'll submit a patch to upstream ecl. The arm64 failures are mysterious runtime failures. The libffi test results for arm64 are good, so I'm wondering if the debian package adds any patches. The jffi failures all look like this: [exec] make[2]: *** No rule to make target '-L/usr/lib/../lib', needed by '/<<PKGBUILDDIR>>/build/jni/jffi/LongDouble.o'. Stop. Perhaps this has something to do with how libffi is installed now? Regardless, it's probably easy to fix whatever it is. The arm64 failures seem like a blocker for the release, which I'm still hoping to get out on Nov 12. Thanks again, AG On Fri, Nov 8, 2019 at 4:21 AM Matthias Klose <doko@ubuntu.com> wrote: > On 24.10.19 13:16, Anthony Green wrote: > > libffi 3.3 release candidate 1 is available for testing... > > > > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 > > started doing some test rebuilds using this version in > https://launchpad.net/~doko/+archive/ubuntu/libffi/+packages > and re-running failed builds against 3.2.1 in > https://launchpad.net/~doko/+archive/ubuntu/libffi-3.2.1/+packages > > Regressions are seen with > > ecl: amd64, i386 > gwrap: arm64 > gauche-c-wrapper: arm64 > jffi: all architectures > polyml: amd64, i386 > python-cffi: arm64 > ruby-ffi: arm64 (but ruby2.5 ftbfs for unrelated reasons) > > I'm following up with more rebuilds. > > Matthias > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-08 14:28 ` Anthony Green @ 2019-11-09 16:04 ` Matthias Klose 2019-11-09 17:46 ` Anthony Green 2019-11-26 8:39 ` Matthias Klose 1 sibling, 1 reply; 25+ messages in thread From: Matthias Klose @ 2019-11-09 16:04 UTC (permalink / raw) To: Anthony Green; +Cc: libffi-discuss On 08.11.19 15:27, Anthony Green wrote: > Thanks, Matthias, this is incredibly helpful. > > For ecl, it looks like they are using FFI_UNIX64 on the 32-bit x86, and > similar for amd64. This is easy to fix, and I'll submit a patch to > upstream ecl. > > The arm64 failures are mysterious runtime failures. The libffi test > results for arm64 are good, so I'm wondering if the debian package adds any > patches. no patches. > The jffi failures all look like this: > > [exec] make[2]: *** No rule to make target '-L/usr/lib/../lib', > needed by '/<<PKGBUILDDIR>>/build/jni/jffi/LongDouble.o'. Stop. > > Perhaps this has something to do with how libffi is installed now? > Regardless, it's probably easy to fix whatever it is. libffi has in the pkg-config file: Libs: -L/usr/lib/../lib Normally pkg-config filters out system directories, but apparently fails for noncanonical paths. And jffi only expects libs. So something packagers should catch, unless you want to remove all the multilib build support, but I'm still awaiting your libffi merge for GCC 10 ;) > The arm64 failures seem like a blocker for the release, which I'm still > hoping to get out on Nov 12. haskell-stack haskell-termonad are the remaining regressions, but I'm not sure if they are related at all. Matthias ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-09 16:04 ` Matthias Klose @ 2019-11-09 17:46 ` Anthony Green 2019-11-10 16:22 ` Matthias Klose 0 siblings, 1 reply; 25+ messages in thread From: Anthony Green @ 2019-11-09 17:46 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss On Sat, Nov 9, 2019 at 11:04 AM Matthias Klose <doko@ubuntu.com> wrote: > > The arm64 failures are mysterious runtime failures. The libffi test > > results for arm64 are good, so I'm wondering if the debian package adds > any > > patches. > > no patches. > I tested g-wrap (upstream) on arm64, and am not able to reproduce the problem. "make check" worked fine with the new libffi. > The jffi failures all look like this: > > > > [exec] make[2]: *** No rule to make target '-L/usr/lib/../lib', > > needed by '/<<PKGBUILDDIR>>/build/jni/jffi/LongDouble.o'. Stop. > > > > Perhaps this has something to do with how libffi is installed now? > > Regardless, it's probably easy to fix whatever it is. > > libffi has in the pkg-config file: Libs: -L/usr/lib/../lib > Normally pkg-config filters out system directories, but apparently fails > for > noncanonical paths. And jffi only expects libs. So something packagers > should > catch, unless you want to remove all the multilib build support, but I'm > still > awaiting your libffi merge for GCC 10 ;) > This may never happen. libffi should probably just come out of GCC, and go can depend on the system libffi. > > The arm64 failures seem like a blocker for the release, which I'm still > > hoping to get out on Nov 12. > > haskell-stack haskell-termonad are the remaining regressions, but I'm not > sure > if they are related at all. > They don't look like libffi issues to me. AG ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-09 17:46 ` Anthony Green @ 2019-11-10 16:22 ` Matthias Klose 0 siblings, 0 replies; 25+ messages in thread From: Matthias Klose @ 2019-11-10 16:22 UTC (permalink / raw) To: Anthony Green; +Cc: libffi-discuss, Ian Lance Taylor On 09.11.19 18:46, Anthony Green wrote: > On Sat, Nov 9, 2019 at 11:04 AM Matthias Klose <doko@ubuntu.com> wrote: > >>> The arm64 failures are mysterious runtime failures. The libffi test >>> results for arm64 are good, so I'm wondering if the debian package adds >> any >>> patches. >> >> no patches. >> > > I tested g-wrap (upstream) on arm64, and am not able to reproduce the > problem. "make check" worked fine with the new libffi. > > >> The jffi failures all look like this: >>> >>> [exec] make[2]: *** No rule to make target '-L/usr/lib/../lib', >>> needed by '/<<PKGBUILDDIR>>/build/jni/jffi/LongDouble.o'. Stop. >>> >>> Perhaps this has something to do with how libffi is installed now? >>> Regardless, it's probably easy to fix whatever it is. >> >> libffi has in the pkg-config file: Libs: -L/usr/lib/../lib >> Normally pkg-config filters out system directories, but apparently fails >> for >> noncanonical paths. And jffi only expects libs. So something packagers >> should >> catch, unless you want to remove all the multilib build support, but I'm >> still >> awaiting your libffi merge for GCC 10 ;) >> > > This may never happen. libffi should probably just come out of GCC, and go > can depend on the system libffi. CCing Ian. Currently libgo doesn't have a --with-system-ffi=<auto|yes|no> option, it always builds with the in-tree libffi. So currently it's not possible, and it's not possible to do that for multilib builds, because the non-default multilib variants are not available by default. For zlib (required for the phobos runtime), I wrote a patch for --with-target-system-zlib=auto using the system zlib when possible, and falling back to the in-tree zlib when the target library is not available. Same for --enable-objc-gc=auto, but in this case this is an optional library. And people are currently not processing patches for GCC/libffi, because they seem to expect a merge at some time ... So maybe clarify what you plan to do with libffi in the GCC sources. Matthias ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-08 14:28 ` Anthony Green 2019-11-09 16:04 ` Matthias Klose @ 2019-11-26 8:39 ` Matthias Klose 2019-11-26 23:25 ` Anthony Green 1 sibling, 1 reply; 25+ messages in thread From: Matthias Klose @ 2019-11-26 8:39 UTC (permalink / raw) To: Anthony Green; +Cc: libffi-discuss On 08.11.19 15:27, Anthony Green wrote: > Thanks, Matthias, this is incredibly helpful. > > For ecl, it looks like they are using FFI_UNIX64 on the 32-bit x86, and > similar for amd64. This is easy to fix, and I'll submit a patch to > upstream ecl. please could you point me to this patch, or attach it here? Matthias ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-26 8:39 ` Matthias Klose @ 2019-11-26 23:25 ` Anthony Green 0 siblings, 0 replies; 25+ messages in thread From: Anthony Green @ 2019-11-26 23:25 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss Here you go. https://paste.centos.org/view/83f87106 On Tue, Nov 26, 2019 at 3:39 AM Matthias Klose <doko@ubuntu.com> wrote: > > On 08.11.19 15:27, Anthony Green wrote: > > Thanks, Matthias, this is incredibly helpful. > > > > For ecl, it looks like they are using FFI_UNIX64 on the 32-bit x86, and > > similar for amd64. This is easy to fix, and I'll submit a patch to > > upstream ecl. > > please could you point me to this patch, or attach it here? > > Matthias > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-10-24 11:17 libffi 3.3 release candidate 1 Anthony Green 2019-10-25 10:08 ` Matthias Klose 2019-11-08 9:21 ` Matthias Klose @ 2019-11-27 7:54 ` Matthias Klose 2019-11-27 9:28 ` Anthony Green 2 siblings, 1 reply; 25+ messages in thread From: Matthias Klose @ 2019-11-27 7:54 UTC (permalink / raw) To: Anthony Green, libffi-discuss On 24.10.19 13:16, Anthony Green wrote: > libffi 3.3 release candidate 1 is available for testing... > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 the libffi-3.3.tar.gz published last Friday now ftbfs on powerpc-linux-gnu: libtool: compile: powerpc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo -c ../src/powerpc/ffi.c -fPIC -DPIC -o src/powerpc/.libs/ffi.o In file included from ../src/powerpc/ffi.c:33: ../src/powerpc/ffi_powerpc.h:65:9: error: â__int128â is not supported on this target 65 | typedef __int128 float128; | ^~~~~~~~ make[3]: *** [Makefile:1274: src/powerpc/ffi.lo] Error 1 make[3]: Leaving directory '/<<PKGBUILDDIR>>/build' make[2]: *** [Makefile:1348: all-recursive] Error 1 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: libffi 3.3 release candidate 1 2019-11-27 7:54 ` Matthias Klose @ 2019-11-27 9:28 ` Anthony Green 0 siblings, 0 replies; 25+ messages in thread From: Anthony Green @ 2019-11-27 9:28 UTC (permalink / raw) To: Matthias Klose; +Cc: libffi-discuss Yes, can you try changing the __int128 to "alignas(16) char[16]" ? https://github.com/libffi/libffi/pull/526 https://github.com/libffi/libffi/issues/531 AG On Wed, Nov 27, 2019 at 2:54 AM Matthias Klose <doko@ubuntu.com> wrote: > > On 24.10.19 13:16, Anthony Green wrote: > > libffi 3.3 release candidate 1 is available for testing... > > > > https://github.com/libffi/libffi/releases/download/v3.3-rc1/libffi-3.3-rc1.tar.gz > > https://github.com/libffi/libffi/releases/tag/v3.3-rc1 > > the libffi-3.3.tar.gz published last Friday now ftbfs on powerpc-linux-gnu: > > libtool: compile: powerpc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I. > -I../include -Iinclude -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wall -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF > src/powerpc/.deps/ffi.Tpo -c ../src/powerpc/ffi.c -fPIC -DPIC -o > src/powerpc/.libs/ffi.o > In file included from ../src/powerpc/ffi.c:33: > ../src/powerpc/ffi_powerpc.h:65:9: error: ‘__int128’ is not supported on this target > 65 | typedef __int128 float128; > | ^~~~~~~~ > make[3]: *** [Makefile:1274: src/powerpc/ffi.lo] Error 1 > make[3]: Leaving directory '/<<PKGBUILDDIR>>/build' > make[2]: *** [Makefile:1348: all-recursive] Error 1 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2019-11-27 9:28 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-24 11:17 libffi 3.3 release candidate 1 Anthony Green 2019-10-25 10:08 ` Matthias Klose 2019-10-25 10:29 ` John Paul Adrian Glaubitz 2019-10-25 14:41 ` Andreas Schwab 2019-10-25 14:44 ` John Paul Adrian Glaubitz 2019-10-25 18:32 ` Andreas Schwab 2019-10-25 18:37 ` John Paul Adrian Glaubitz 2019-10-25 19:04 ` Andreas Schwab 2019-10-25 19:07 ` John Paul Adrian Glaubitz 2019-10-26 11:35 ` Anthony Green 2019-10-26 12:54 ` Anthony Green 2019-10-31 19:49 ` Anthony Green 2019-10-31 20:32 ` John Paul Adrian Glaubitz [not found] ` <CAAs=koj3HU08uxx36809NcPYe33xvEjUDsLwJc_9R8V4tbr9Zg@mail.gmail.com> 2019-10-31 22:16 ` John Paul Adrian Glaubitz 2019-11-01 8:01 ` John Paul Adrian Glaubitz 2019-11-01 22:24 ` John Paul Adrian Glaubitz 2019-11-08 9:21 ` Matthias Klose 2019-11-08 14:28 ` Anthony Green 2019-11-09 16:04 ` Matthias Klose 2019-11-09 17:46 ` Anthony Green 2019-11-10 16:22 ` Matthias Klose 2019-11-26 8:39 ` Matthias Klose 2019-11-26 23:25 ` Anthony Green 2019-11-27 7:54 ` Matthias Klose 2019-11-27 9:28 ` Anthony Green
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).