Bug #7921

Cross-compiling ruby_2_0_0 to Windows is failing (rb_w32_pow)

Added by Luis Lavena about 1 year ago. Updated 8 months ago.

[ruby-core:52742]
Status:Third Party's Issue
Priority:Normal
Assignee:Nobuyoshi Nakada
Category:build
Target version:2.1.0
ruby -v:ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.1] Backport:

Description

=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 ‘rbw32pow’:
../include/ruby/win32.h:787:5: error: implicit declaration of function ‘controlfp’
../include/ruby/win32.h:788:16: error: ‘
PC64’ 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 mingwfloat.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 @@ rbw32pow(double x, double y)
return powl(x, y);
}
#elif defined(_MINGW64VERSIONMAJOR)
+#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

History

#1 Updated by Nobuyoshi Nakada about 1 year ago

  • Status changed from Assigned to Feedback

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

#2 Updated by Luis Lavena about 1 year ago

=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 mingwfloat.h, perhaps is a header issue of this particular version of this version.

=end

#3 Updated by Luis Lavena about 1 year ago

  • Status changed from Feedback to Assigned
  • Assignee changed from Luis Lavena to 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, mingwfloat.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.

#4 Updated by Nobuyoshi Nakada about 1 year ago

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.

#5 Updated by Luis Lavena about 1 year ago

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-bini686-darwin20110822.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/

#6 Updated by Yusuke Endoh about 1 year ago

Could the version of mingw build rc2?

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

Yusuke Endoh mame@tsg.ne.jp

#7 Updated by Luis Lavena about 1 year ago

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 ‘rbw32pow’:
../include/ruby/win32.h:787:5: error: implicit declaration of function ‘controlfp’
../include/ruby/win32.h:788:16: error: ‘
PC64’ 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 "mingwfloat.h" does always exist when defined(_MINGW64VERSION_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 MCWPC or PC64 is undefined, then we can assume include of mingwfloat.h is required.

#8 Updated by Yusuke Endoh about 1 year ago

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 mame@tsg.ne.jp

#9 Updated by Luis Lavena about 1 year ago

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.

#10 Updated by Nobuyoshi Nakada about 1 year ago

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

#11 Updated by Koichi Sasada about 1 year ago

  • Target version changed from 2.0.0 to 2.1.0

2.0.0 was released.

#12 Updated by Luis Lavena about 1 year ago

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.

#13 Updated by Usaku NAKAMURA about 1 year ago

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.

#14 Updated by Hiroshi Shirosaki about 1 year ago

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

$ cd mingw-w32-1.0-bini686-darwin20110822
$ 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.

#15 Updated by Yui NARUSE 9 months ago

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

What is this status?

#16 Updated by Luis Lavena 9 months ago

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

#17 Updated by Sergey Avseyev 8 months ago

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

#18 Updated by Luis Lavena 8 months ago

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

Also available in: Atom PDF