From: Bas Groothedde <lua@xoru.net>
To: libffi-discuss@sourceware.org
Subject: Building the latest LibFFI for Windows
Date: Thu, 08 Feb 2018 21:49:00 -0000 [thread overview]
Message-ID: <163cd931d34d07e248fa49b9a836a213@xoru.net> (raw)
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
next reply other threads:[~2018-02-08 21:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 21:49 Bas Groothedde [this message]
2018-02-26 11:15 ` Anthony Green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=163cd931d34d07e248fa49b9a836a213@xoru.net \
--to=lua@xoru.net \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).