From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111227 invoked by alias); 8 Nov 2019 14:28:02 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 111219 invoked by uid 89); 8 Nov 2019 14:28:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=H*Ad:U*libffi-discuss, H*c:alternative X-HELO: mail-lj1-f175.google.com Received: from mail-lj1-f175.google.com (HELO mail-lj1-f175.google.com) (209.85.208.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2019 14:28:00 +0000 Received: by mail-lj1-f175.google.com with SMTP id 139so6432859ljf.1 for ; Fri, 08 Nov 2019 06:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moxielogic-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x612b+gAZVDH5FYsZd31+x1RhuUQ84+Jo1t8oT59dtU=; b=Or/+AOfZsFXlweBBWXE13nzRSKH9WcRhKAxEfmy2mMbadFI+U54eQPSve5aZVB4x8y QuaddIUez7lQD/P0H+K8l5f/F1yrqq/ALZEOsAHTWzyM3PEDu+0/+QETIz4pIroX/RC+ H5UYgT45CqDuLk5LNjvEpVGAW8f9JkC9yNllnP35WffloQOFIPoCiRcCPqIBf+gEBatT CgNK0mqZSr1Kaca/nlCh1vMUb9LmyiSUTZW0NpRdv5pOAEjpf4Dt/Lnk/2+2prjW+Q4+ hXhAkFdeh4nuvqqAtLRzKNqniCHt4RV12n4nPOOi+oqrgT8N7l4fQxa4kqrVSJysEjYY GjNw== MIME-Version: 1.0 References: In-Reply-To: From: Anthony Green Date: Fri, 08 Nov 2019 14:28:00 -0000 Message-ID: Subject: Re: libffi 3.3 release candidate 1 To: Matthias Klose Cc: libffi-discuss Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00057.txt.bz2 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 '/<>/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 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 >