Any plans to support Mingw64-64 4.9.1

[wkwood]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@sodabrew see the implications here: #297

[johnnyshields]

This can be closed, will be addressed by RubyInstaller2

[larskanis]

This is resolved in https://github.com/oneclick/rubyinstaller2 .