From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87963 invoked by alias); 10 Nov 2019 16:22:34 -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 87953 invoked by uid 89); 10 Nov 2019 16:22:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=green, falling, HTo:U*green, Green X-HELO: einhorn-mail.in-berlin.de Received: from einhorn-mail.in-berlin.de (HELO einhorn-mail.in-berlin.de) (217.197.80.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 10 Nov 2019 16:22:33 +0000 X-Envelope-From: doko@ubuntu.com Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id xAAGMS1J015248 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 Nov 2019 17:22:28 +0100 Subject: Re: libffi 3.3 release candidate 1 To: Anthony Green Cc: libffi-discuss , Ian Lance Taylor References: <288adc9e-ad74-7813-eed8-e94dcb4e185f@ubuntu.com> From: Matthias Klose Message-ID: <1adc7643-fc2f-a864-8f6c-19b30dd45de1@ubuntu.com> Date: Sun, 10 Nov 2019 16:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00063.txt.bz2 On 09.11.19 18:46, Anthony Green wrote: > On Sat, Nov 9, 2019 at 11:04 AM Matthias Klose 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 '/<>/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= 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