Bug #7921: Cross-compiling ruby_2_0_0 to Windows is failing (rb_w32_pow)

• Status: Third Party's Issue
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: 2.1.0
• ruby -v: ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.1]

[luislavena (Luis Lavena)]

=begin
Hello,

Cross-compilation of Ruby targeting Windows (using MinGW) is an important tool for Linux/OSX developers to provide pre-compiled binary gems for Windows users. Having cross-compilation failing for Ruby 2.0 will complicate the installation of gems for the new version, as developers will not be able to provide these binaries for suers.

The error that is being triggered is coming from undefined elements:

compiling ../dln.c
In file included from ../include/ruby/defines.h:153:0,
from ../include/ruby/ruby.h:70,
from ../dln.c:13:
../include/ruby/win32.h: In function ‘rb_w32_pow’:
../include/ruby/win32.h:787:5: error: implicit declaration of function ‘_controlfp’
../include/ruby/win32.h:788:16: error: ‘_PC_64’ undeclared (first use in this function)
../include/ruby/win32.h:788:16: note: each undeclared identifier is reported only once for each function it appears in
../include/ruby/win32.h:788:24: error: ‘_MCW_PC’ undeclared (first use in this function)
make: *** [dln.o] Error 1

This is easily fixed by including MinGW private header _mingw_float.h:

diff --git a/include/ruby/win32.h b/include/ruby/win32.h
index a2eec0c..494b522 100644
--- a/include/ruby/win32.h
+++ b/include/ruby/win32.h
@@ -776,6 +776,7 @@ rb_w32_pow(double x, double y)
return powl(x, y);
}
#elif defined(__MINGW64_VERSION_MAJOR)
+#include <_mingw_float.h>
/*

• Set floating point precision for pow() of mingw-w64 x86.
• With default precision the result is not proper on WinXP.

I want to test this further with other cross-compiler and native compiler combinations before commit, but wanted to open this up before official 2.0 release.

Thank you.
=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Feedback

With which mingw do you fail?
I haven't seen that error.

[luislavena (Luis Lavena)]

=begin
nobu (Nobuyoshi Nakada) wrote:

With which mingw do you fail?
I haven't seen that error.

This fails with mingw-w64 4.5.4:

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.5.4 20110822 (prerelease)

I'm testing against 4.7.2 on OSX too, seems float.h is not including _mingw_float.h, perhaps is a header issue of this particular version of this version.

=end

[luislavena (Luis Lavena)]

• Status changed from Feedback to Assigned
• Assignee changed from luislavena (Luis Lavena) to nobu (Nobuyoshi Nakada)

nobu (Nobuyoshi Nakada) wrote:

With which mingw do you fail?
I haven't seen that error.

Hello Nobu-san,

I can confirm this only happens with that particular version. Even if float.h is included, _mingw_float.h seems is not included.

I see no harm in applying the patch I proposed before, but I'm away of the computer that have my commit credentials.

Nobu-san, can you commit the patch so 2.0.0-p0 works for this scenario?

Thank you.

[nobu (Nobuyoshi Nakada)]

I wonder if that header can be always included unconditionally.

BTW, what package are you using, Luis?
Seems I have to install same package too.

[luislavena (Luis Lavena)]

nobu (Nobuyoshi Nakada) wrote:

I wonder if that header can be always included unconditionally.

I think only mingw-w64 suffers this issue.

BTW, what package are you using, Luis?
Seems I have to install same package too.

I'm using mingw-w32-1.0-bin_i686-darwin_20110822.tar.bz2 package from mingw-w64 project.

URL:

http://downloads.sourceforge.net/mingw-w64/mingw-w32-1.0-bin_i686-darwin_20110822.tar.bz2

On linux I'm using rubenvb builds:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/

[mame (Yusuke Endoh)]

Could the version of mingw build rc2?

I'm not sure if the file "_mingw_float.h" does always exist when defined(__MINGW64_VERSION_MAJOR) is true.

--
Yusuke Endoh [e-mail]

[luislavena (Luis Lavena)]

mame (Yusuke Endoh) wrote:

Could the version of mingw build rc2?

I no longer have "mingw" installed on this box, only mingw-w64 version of compiler.

This version of compiler cannot build rc2, same error as the report:

compiling ../dln.c
In file included from ../include/ruby/defines.h:153:0,
from ../include/ruby/ruby.h:70,
from ../dln.c:13:
../include/ruby/win32.h: In function ‘rb_w32_pow’:
../include/ruby/win32.h:787:5: error: implicit declaration of function ‘_controlfp’
../include/ruby/win32.h:788:16: error: ‘_PC_64’ undeclared (first use in this function)
../include/ruby/win32.h:788:16: note: each undeclared identifier is reported only once for each function it appears in
../include/ruby/win32.h:788:24: error: ‘_MCW_PC’ undeclared (first use in this function)
make: *** [dln.o] Error 1

I'm not sure if the file "_mingw_float.h" does always exist when defined(__MINGW64_VERSION_MAJOR) is true.

This is a known problem of old mingw-w64 headers, which has been solved in newer versions.

RubyInstaller CI uses newer (4.7.2) version, so the problem is not seeing there.

Since mingw-w64 no longer provides darwin builds, I cannot test recent versions for cross-compilation but if _MCW_PC or _PC_64 is undefined, then we can assume include of _mingw_float.h is required.

[mame (Yusuke Endoh)]

Then, is it a bug of the old mingw-w64?
If so, I don't think this is a urgent task; let's address it after p0.

--
Yusuke Endoh [e-mail]

[luislavena (Luis Lavena)]

mame (Yusuke Endoh) wrote:

Then, is it a bug of the old mingw-w64?
If so, I don't think this is a urgent task; let's address it after p0.

If you read my original report: release of p0 with this issue will result in developers unable to provide binaries of some gems for Windows users.

Lot of Ruby developers cross-compile gems for Windows from OSX/Linux.

The definition of "old" do not apply here. We are talking about specific GCC 4.5.4 release, which lot of Ruby developers have installed to cross-compile binaries for Windows users.

Newer versions have solved this, yet none of the developers have upgraded to those versions.

Releasing p0 with this issue will break cross-compilation and will cause more damage.

[nobu (Nobuyoshi Nakada)]

It sounds just like newer mingw64 package is desired, to me.

[ko1 (Koichi Sasada)]

• Target version changed from 2.0.0 to 2.1.0

2.0.0 was released.

[luislavena (Luis Lavena)]

ko1 (Koichi Sasada) wrote:

2.0.0 was released.

Thank you Koichi for letting me now that 2.0.0-p0 is out and that will break gem compilers expectations.

2.0.0 introduces a new ABI version (2.0.0) that differs from 1.9.3 (1.9.1), this means that Windows users will not be able to install existing pre-compiled binaries.

These Windows users will now depend on OSX/Linux gem authors and other developers to compile those binary gems for them.

Problem is the current cross-compiler they have installed and worked great for 1.8.7, 1.9.2 and 1.9.3 is now useless, since 2.0.0 cannot be compiled with it.

They will need a new cross-compiler that most likely is going to require them recompile all the existing versions of Ruby they target for their gems.

So, by saying "newer mingw64 package is desired", you just broke the developers environment and force them solve that in order to provide a solution to a platform they don't care.

The work done with rake-compiler made it easy for those developers provide those gems; now with broken 2.0.0 they might simply decide is too much work to keep doing it (lot of developers don't care about Windows at all)

I offered myself to be mingw/mingw-w64 platform maintainer, but was unable to commit the changes yesterday since I was away of my development machine.

Explained the reasoning on why this workaround was required and it got simply ignored. It would have only taken 2 minutes to commit and we could have discussed better solutions for next patchlevel.

Now, gem authors will have to wait for next patchlevel (whenever it comes) to actually provide binaries.

Isn't my opinion worth it? The outcome of not committing that single workaround line will have a huge ramification, which now I will have to deal with.

[usa (Usaku NAKAMURA)]

I am not knowledgeable about mingw.
However, the version of mingw seems to have a very important meaning for luis,
doesn't it?
If so, luis, simply you should correct trunk and make a backport ticket for 2.0.0.

[h.shirosaki (Hiroshi Shirosaki)]

It looks like wrong header file for float.h. Just copying the header file solves that.

$ cd mingw-w32-1.0-bin_i686-darwin_20110822
$ cp i686-w64-mingw32/include/float.h lib/gcc/i686-w64-mingw32/4.5.4/include/float.h

Cross compiling ruby completed on my test.

[naruse (Yui NARUSE)]

• Status changed from Assigned to Feedback
• Priority changed from 6 to Normal

What is this status?

[luislavena (Luis Lavena)]

• Status changed from Feedback to Third Party's Issue

I'm closing this out as 3rd party issue (mingw-w64 incorrect header package)

This has been solved in latest versions of mingw-w64 packages.

Thank you.

[avsej (Sergey Avseyev)]

Could you specify the versions of mingw-w64 since this issue has been fixed?

[luislavena (Luis Lavena)]

avsej (Sergey Avseyev) wrote:

Could you specify the versions of mingw-w64 since this issue has been fixed?

Instead of automated builds packages, usage of specific builds (like rubenvb) had this issue solved.

A developer created "rake-compiler-dev-box" to ease with version matching and have a functional Linux cross-compiler box:

https://github.com/tjschuck/rake-compiler-dev-box

See this specific pull with the final round of changes:

https://github.com/tjschuck/rake-compiler-dev-box/pull/2