libffi 3.3 release candidate 1

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

libffi 3.3 release candidate 1

Anthony Green
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Matthias Klose-6
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
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Anthony Green
In reply to this post by Matthias Klose-6
On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <[hidden email]> 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



>
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Anthony Green
In reply to this post by Matthias Klose-6
On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Anthony Green
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 <[hidden email]> wrote:

> On Fri, Oct 25, 2019 at 6:08 AM Matthias Klose <[hidden email]> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
Hi Anthony!

> On Oct 31, 2019, at 9:06 PM, Anthony Green <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
In reply to this post by John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

ffi-sh4.log (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

John Paul Adrian Glaubitz
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

ffi-m68k.log (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Matthias Klose-6
In reply to this post by Anthony Green
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
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Anthony Green
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Matthias Klose-6
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
Reply | Threaded
Open this post in threaded view
|

Re: libffi 3.3 release candidate 1

Anthony Green
On Sat, Nov 9, 2019 at 11:04 AM Matthias Klose <[hidden email]> 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
12