public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
* Building the latest LibFFI for Windows
@ 2018-02-08 21:49 Bas Groothedde
  2018-02-26 11:15 ` Anthony Green
  0 siblings, 1 reply; 2+ messages in thread
From: Bas Groothedde @ 2018-02-08 21:49 UTC (permalink / raw)
  To: libffi-discuss

 

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Building the latest LibFFI for Windows
  2018-02-08 21:49 Building the latest LibFFI for Windows Bas Groothedde
@ 2018-02-26 11:15 ` Anthony Green
  0 siblings, 0 replies; 2+ messages in thread
From: Anthony Green @ 2018-02-26 11:15 UTC (permalink / raw)
  To: lua; +Cc: libffi-discuss

Hi Bas,

  My suggestion is to only work with the git sources right now.
32-bit builds with the MS tools should still work.  Could you open a
issue on github with the console output of that build attempt?  I may
also need to see config.log if it was created.

Thanks!

AG

On Thu, Feb 8, 2018 at 4:48 PM, Bas Groothedde <lua@xoru.net> wrote:
>
>
> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-02-26 11:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-08 21:49 Building the latest LibFFI for Windows Bas Groothedde
2018-02-26 11:15 ` Anthony Green

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).