Any plans to support Mingw64-64 4.9.1 #232

Open
wkwood opened this Issue Jul 30, 2014 · 10 comments

Projects

None yet

4 participants

@wkwood
wkwood commented Jul 30, 2014

Any official plans to support Mingw64-64 4.9.1? Right now 4.7.2 is a bit stale and I hit a -O3 optimization bug recently with it. FYI Here's my recent changes to mingw64.rb. I'm getting a stable build with it.

COMPILERS['mingw64-64-4.9.1'] =
OpenStruct.new(
:version => 'mingw64-64-4.9.1',
:programs => [ :gcc, :cpp, :'g++' ],
:program_prefix => nil,
:url_1 => 'http://downloads.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-win32/seh',
:url_2 => 'http://downloads.sourceforge.net/mingw',
:url_3 => 'http://downloads.sourceforge.net/gnuwin32',
:target => 'sandbox/devkit/mingw',
:relocate => 'sandbox/devkit/mingw/mingw64',
:host => 'x86_64-w64-mingw32',
:files => {
:url_1 => [
'x86_64-4.9.1-release-win32-seh-rt_v3-rev0.7z',
],
:url_2 => [
'autoconf2.1-2.13-4-mingw32-bin.tar.lzma',
'autoconf2.5-2.68-1-mingw32-bin.tar.lzma',
'autoconf-10-1-mingw32-bin.tar.lzma',
'automake1.11-1.11.1-1-mingw32-bin.tar.lzma',
'automake-4-1-mingw32-bin.tar.lzma',
'libexpat-2.0.1-1-mingw32-dll-1.tar.gz',
'libtool-2.4-1-mingw32-bin.tar.lzma',
'bsdtar-2.8.3-1-mingw32-bin.tar.bz2',
'bsdcpio-2.8.3-1-mingw32-bin.tar.bz2',
'libarchive-2.8.3-1-mingw32-dll-2.tar.bz2',
'libbz2-1.0.5-2-mingw32-dll-2.tar.gz',
'liblzma-4.999.9beta_20100401-1-mingw32-dll-1.tar.bz2',
'libz-1.2.3-1-mingw32-dll-1.tar.gz'
],
:url_3 => [
'which-2.20-bin.zip'
],
}
)

@luislavena
Member

Please take a look to some existing branches for msys2 and others that
introduce 4.9.x

Problem with using 4.9.1 is that all existing libraries are compiled with
older versions of gcc and that present some problems.

Will provide a proper response once I can use my computer.

@jonforums
Member

If you haven't already discovered it, monitor and experiment with this edge branch https://github.com/oneclick/rubyinstaller/commits/jf/dk-edge

Use with the standard warning: "the branch is 100% unsupported and 100% unofficial. You are on your own." That said, I currently build all my 32bit 2.1.x rubies (and corresponding native gems) with this branch using dkver=mingw64-32-4.9.1.

As Luis alluded to, don't mix-n-match toolchains used to build ruby and any native gems you build. There may also be lurking mix-n-match toolchain issues with the binary fat gems if build ruby with 4.9.1 from this branch.

@wkwood
wkwood commented Jul 30, 2014

I latched onto it and it appears to work fine. Getting back to the OP what’s the plans for supporting 4.8 or 4.9 on the trunk?

@luislavena
Member

Getting back to the OP what’s the plans for supporting 4.8 or 4.9 on the trunk?

In order to support 4.8 or 4.9, it will require complete recompile of all the dependencies built that Ruby uses.

Not only that, but the binaries produced by those might not be compatible with the existing ones, so that is opening Pandora's box just for the fun of it.

Last time I tested things like Fiddle (which depends on FFI) and GDBM test failed.

Please go ahead and try it yourself and let us know. We all will benefit from the knowledge.

@wkwood
wkwood commented Jul 30, 2014

Okay I will let you know
On Jul 30, 2014 2:32 PM, "Luis Lavena" notifications@github.com wrote:

Getting back to the OP what’s the plans for supporting 4.8 or 4.9 on the
trunk?

In order to support 4.8 or 4.9, it will require complete recompile of all
the dependencies built that Ruby uses.

Not only that, but the binaries produced by those might not be compatible
with the existing ones, so that is opening Pandora's box just for the fun
of it.

Last time I tested things like Fiddle (which depends on FFI) and GDBM test
failed.

Please go ahead and try it yourself and let us know. We all will benefit
from the knowledge.


Reply to this email directly or view it on GitHub
#232 (comment)
.

@wkwood
wkwood commented Jul 31, 2014

FYI using CHECKOUT=1 DKVER=mingw64-64-4.9.1 –

Fiddle is working to some extent, I have a sample app and it at least is able to load a Windows DLL and invoke the functions.

I can’t get FFI to install, it seems that the ruby path is omitting the .exe when the Makefile is generated.

d:/ruby/bin/ruby.exe extconf.rb

checking for ffi.h... no

checking for ffi.h in /usr/local/include,/usr/include/ffi... no

checking for rb_thread_blocking_region()... yes

checking for rb_thread_call_with_gvl()... yes

checking for rb_thread_call_without_gvl()... yes

checking for ffi_prep_cif_var()... no

creating extconf.h

creating Makefile

make "DESTDIR=" clean

make "DESTDIR="

generating ffi_c-x64-mingw32.def

/bin/sh: /d/ruby/bin/ruby: No such file or directory

Makefile:235: recipe for target 'ffi_c-x64-mingw32.def' failed

make: *** [ffi_c-x64-mingw32.def] Error 127

make failed, exit code 2

From: Will Wood [mailto:wkwood@gmail.com]
Sent: Wednesday, July 30, 2014 4:57 PM
To: oneclick/rubyinstaller
Subject: Re: [rubyinstaller] Any plans to support Mingw64-64 4.9.1 (#232)

Okay I will let you know

On Jul 30, 2014 2:32 PM, "Luis Lavena" <notifications@github.com mailto:notifications@github.com > wrote:

Getting back to the OP what’s the plans for supporting 4.8 or 4.9 on the trunk?

In order to support 4.8 or 4.9, it will require complete recompile of all the dependencies built that Ruby uses.

Not only that, but the binaries produced by those might not be compatible with the existing ones, so that is opening Pandora's box just for the fun of it.

Last time I tested things like Fiddle (which depends on FFI) and GDBM test failed.

Please go ahead and try it yourself and let us know. We all will benefit from the knowledge.


Reply to this email directly or view it on GitHub #232 (comment) . https://github.com/notifications/beacon/4682752__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyMjM3NTE1NSwiZGF0YSI6eyJpZCI6MzgzOTkyNTJ9fQ==--475a9348cd92a30b249676750c6a17832c4f8fd3.gif

@luislavena
Member

To satisfy ffi gem dependency you need ffi package.

Use ffi knapsack package as detailed in several posts in the rubyinstaller
mailing list.

My original message said about fiddle, not ffi gem, as ffi gem is a special
case.

Sorry for top posting. Sent from mobile.
On Jul 31, 2014 1:20 AM, "wkwood" notifications@github.com wrote:

FYI using CHECKOUT=1 DKVER=mingw64-64-4.9.1 -

Fiddle is working to some extent, I have a sample app and it at least is
able to load a Windows DLL and invoke the functions.

I can't get FFI to install, it seems that the ruby path is omitting the
.exe when the Makefile is generated.

d:/ruby/bin/ruby.exe extconf.rb

checking for ffi.h... no

checking for ffi.h in /usr/local/include,/usr/include/ffi... no

checking for rb_thread_blocking_region()... yes

checking for rb_thread_call_with_gvl()... yes

checking for rb_thread_call_without_gvl()... yes

checking for ffi_prep_cif_var()... no

creating extconf.h

creating Makefile

make "DESTDIR=" clean

make "DESTDIR="

generating ffi_c-x64-mingw32.def

/bin/sh: /d/ruby/bin/ruby: No such file or directory

Makefile:235: recipe for target 'ffi_c-x64-mingw32.def' failed

make: *** [ffi_c-x64-mingw32.def] Error 127

make failed, exit code 2

From: Will Wood [mailto:wkwood@gmail.com]
Sent: Wednesday, July 30, 2014 4:57 PM
To: oneclick/rubyinstaller
Subject: Re: [rubyinstaller] Any plans to support Mingw64-64 4.9.1 (#232)

Okay I will let you know

On Jul 30, 2014 2:32 PM, "Luis Lavena" <notifications@github.com <mailto:
notifications@github.com> > wrote:

Getting back to the OP what's the plans for supporting 4.8 or 4.9 on the
trunk?

In order to support 4.8 or 4.9, it will require complete recompile of all
the dependencies built that Ruby uses.

Not only that, but the binaries produced by those might not be compatible
with the existing ones, so that is opening Pandora's box just for the fun
of it.

Last time I tested things like Fiddle (which depends on FFI) and GDBM test
failed.

Please go ahead and try it yourself and let us know. We all will benefit
from the knowledge.

Reply to this email directly or view it on GitHub <
https://github.com/oneclick/rubyinstaller/issues/232#issuecomment-50683145>
. <
https://github.com/notifications/beacon/4682752__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyMjM3NTE1NSwiZGF0YSI6eyJpZCI6MzgzOTkyNTJ9fQ==--475a9348cd92a30b249676750c6a17832c4f8fd3.gif>

Reply to this email directly or view it on GitHub
#232 (comment)
.

@jonforums
Member

An FYI that may not affect you if you don't manually rebuild the dependencies.

Both the gcc 4.8.x and 4.9.x based toolchains (32 and 64bit) using mingw-w64 have changed how they depend upon libgcc. To prevent your built artifacts from depending upon the libgcc DLL, you must now build with -static-libgcc. On the jf/dk-edge branch I've already take care of this for ruby with commits like this.

However, if you decide to rebuild deps like like openssl (I do so as to get better openssl 1.0.1h support and libffi 3.1) you'll need to ensure your deps do not runtime link to libgcc by doing things like this when rebuilding some of the deps.

@sodabrew

Could I bump this thread? I found that the MinGW in present versions of DevKit are not providing some newer (read: available since Windows XP...) getaddrinfo constants:
eventmachine/eventmachine#659

These were added to MinGW somewhat recently: http://sourceforge.net/p/mingw-w64/mailman/message/33056995/

@luislavena
Member

@sodabrew see the implications here: #297

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment