From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76897 invoked by alias); 8 Feb 2018 21:49:57 -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 76379 invoked by uid 89); 8 Feb 2018 21:49:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,HTML_MESSAGE,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=quest, GitHub, sk:libffi-, sk:libffi X-HELO: xorunetv2.colo.transip.net Received: from imagine-programming.com (HELO xorunetv2.colo.transip.net) (149.210.201.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 21:49:54 +0000 Received: from mail.xoru.net (localhost [127.0.0.1]) by xorunetv2.colo.transip.net (Postfix) with ESMTP id 2C5021C18CF for ; Thu, 8 Feb 2018 22:48:48 +0100 (CET) MIME-Version: 1.0 Date: Thu, 08 Feb 2018 21:49:00 -0000 From: Bas Groothedde To: libffi-discuss@sourceware.org Subject: Building the latest LibFFI for Windows Reply-To: lua@xoru.net Mail-Reply-To: lua@xoru.net Message-ID: <163cd931d34d07e248fa49b9a836a213@xoru.net> X-Sender: lua@xoru.net User-Agent: Roundcube Webmail/RCMAIL_VERSION Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018/txt/msg00006.txt.bz2 Hi there list! First of all, I hope that this list is still active. I'm trying to learn more about the libffi source in the hopes of utilising it and hopefully contributing to this project. I encountered a problem with libffi-3.2.1, build with msvc 2017 in cygwin from source (sourceware.org:/pub/libffi/libffi-3.2.1.tar.gz [1]). With a little tweaking in the build script I managed to get a nice static x86 and x64 library build of libffi. Wonderful! I was then happily using the library until I encountered that on x86 Windows, the stdcall ABI in closures are a bit grumpy. Using the ABI in callbacks for Windows API calls, like EnumChildWindows, crashes the program and raises a 'Stack overflow' exception. This is a massive problem for me, as one of the biggest reasons I'm using libffi is to support API access from a scripting language. I have seen many reports on this issue, and many possible fixes, however none of the fixes I encountered seemed to work in the 3.2.1 sources I downloaded. If anyone has a fix for that version, I'd love to have it; as it successfully builds with msvc on x86 and x64 platforms. The next thing I tried in my desperate quest for a solution is to fetch the latest version of the libffi source of GitHub, and try to compile that with my cygwin / msvc setup. (I need the Windows build to be a static library produced by msvc) - however to my surprise the x64 build went very well, but the x86 build yields an 'platform not supported' error. Is there any way I can still build with msvc for x86, or am I lost completely here? Building with mingw or gcc causes issues in the software the library is going to be linked in, due to the fact a newer standard library is linked (which is not available in that software). Thanks for your time, and hopefully someone will understand what my rambling is about. Cheers! Bas -- ------------------------- Bas Groothedde Imagine Programming Links: ------ [1] ftp://sourceware.org/pub/libffi/libffi-3.2.1.tar.gz