Forum: Ruby-core [Ruby 1.9-Bug#3889][Open] Incorrectly detected i686-w64-mingw32 as x64-mingw

C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-09-29 17:57
(Received via mailing list)
Bug #3889: Incorrectly detected i686-w64-mingw32 as x64-mingw
http://redmine.ruby-lang.org/issues/show/3889

Author: Luis Lavena
Status: Open, Priority: Normal
Category: build, Target version: 1.9.x
ruby -v: 1.9.3dev and 1.9.2

Hello,

*-w64-mingw32 repesent the GCC compilers and headers by mingw-w64
project:

http://mingw-w64.sf.net/

This project provides compilers in 2 architectures: i686 for 32bits and
x86_64 for 64bits Windows.

There has been a previous discussion about this with wanabe at
[ruby-core:32565]

The latest changes and regularization introduced in r29324, r29347,
r29354, r29365 complicates things further than wanabe patch in the above
ruby-core thread.

1) configure --host=i686-w64-mingw32 generates "x64-mingw" configuration
file

This is incorrect, i686 indicates the architecture according to GCC
tripled (arch-vendor-os)

2) mingw != mingw32

Dropping 32 of mingw (which is the os) now means possible breakage of
RubyGems.

$ ruby -rubygems -ve "puts Gem::Platform.new 'x86-mingw'"
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]
x86-unknown

3) i686-pc vs x86_64-w64 vs mingw32 vs mingw64

Until today there is no official (ala: mingw.org) 64bits version of GCC
for Windows. this is because both teams fractured long ago.

the mingw64 shortcut introduced in config.sub has no point as there is
no "-pc-" vendor for these compilers

It is important to differentiate that i686 and x86_64 has nothing to do
with vendor (pc or w64) and os (mingw32) must remain for compatibility.
There is not such thing as "mingw64".

In an ideal world, it could be, but we don't live in an ideal world.

Please consider these changes:

1) --host=i686-w64-mingw32 should be treated as i386-mingw32

2) --host=x86_64-w64-mingw32 should be treated as x86_64-mingw32

3) consider arch and os, please ignore vendor in your config.sub rules.

Thank you.
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-09-29 18:02
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.


One thing I forgot to mention.

If the revisions I've mentioned above are backported to 1.9.2 (which
seems is been prepared for another release) these will break compilation
of RubyInstaller packages.

Thank you.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-10-03 09:29
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.

File 0001-Remove-migw64-normalization.patch added
File 0002-Unify-mkexport-symbols-for-32-64-MinGW.patch added

Hello,

Please find attached the corrections to tool/config.sub to properly
detect i686-w64-mingw32 as i386-mingw32 and x86_64-w64-mingw32 as
x86_64-mingw32

Also, find another patch that unifies MinGW 32 and 64 bits mkexports

Please consider them to replace the current ones.

Thank you.

----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 _ wanabe (Guest)
on 2010-10-03 17:07
(Received via mailing list)
Issue #3889 has been updated by _ wanabe.

Status changed from Open to Closed
% Done changed from 0 to 100

This issue was solved with changeset r29402.
Luis, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Usaku NAKAMURA (Guest)
on 2010-10-05 06:38
(Received via mailing list)
Issue #3889 has been updated by Usaku NAKAMURA.


Who make the final decision?
Wanabe, are you (or, do you want to become) the maintainer of mingw
port?

I'm very dissatisfied with the current state, but I don't have a mind to
object to the maintainer's decision.
Therefore, I ask it again.
Who is the maintainer and who make the final decision?

----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Shyouhei Urabe (Guest)
on 2010-10-05 07:04
(Received via mailing list)
Issue #3889 has been updated by Shyouhei Urabe.

Status changed from Closed to Open

Reopening.  We need a port maintainer.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
1a89a8ff89c39148448a228115925b29?d=identicon&s=25 wanabe (Guest)
on 2010-10-05 14:03
(Received via mailing list)
2010/10/5, Usaku NAKAMURA <redmine@ruby-lang.org>:
> Who make the final decision?
> Wanabe, are you (or, do you want to become) the maintainer of mingw port?

No, I am not. (and I do not want to)

> I'm very dissatisfied with the current state, but I don't have a mind to
> object to the maintainer's decision.
> Therefore, I ask it again.
> Who is the maintainer and who make the final decision?

I'm very sorry to commit r29320 hastily.
This is really, really my fault.

I asked for a Nakada-san's advice of this issue.
Because he is the maintainer of mingw32.
He said config.sub should be reverted to automake-1.11.1's.
I did it because I thought it can be covering my losses.

And the change of win32/mkexports.rb is my fault.
I guessed that there is no effect for other platform by this change.

But now I realize that I exceeded my authority.
I want to ask back to the maintainer of win32/mkexports.rb (who?) for
acceptability of it.
I guess I should revert the change until hear this decision, shouldn't
I?
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 _ wanabe (Guest)
on 2010-10-05 15:27
(Received via mailing list)
Issue #3889 has been updated by _ wanabe.


I commited r29411 to revert win32/mkexports.rb.
Sorry again.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-10-05 16:27
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.


Hello,

Please apologize my lack of understanding of Ruby development hierarchy,
but the revert of 'mingw' specifics in mkexports breaks the mingw-w64
work.

Who is the maintainer that provides "best effort" in relation to MinGW
support? I would like to discuss this and future MinGW work without
causing you guys lot of conflicts.

Thank you.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3889
Be30361bb0b0c495e3077db43ad84b56?d=identicon&s=25 Aaron Patterson (Guest)
on 2010-10-05 19:16
(Received via mailing list)
On Tue, Oct 05, 2010 at 08:59:06PM +0900, wanabe wrote:
>
> I'm very sorry to commit r29320 hastily.
> This is really, really my fault.
>
> I asked for a Nakada-san's advice of this issue.
> Because he is the maintainer of mingw32.

Maybe we should give Luis commit access.  He does so much work shipping
mingw builds.  It seems that he would be a good person to help.
Be30361bb0b0c495e3077db43ad84b56?d=identicon&s=25 Aaron Patterson (Guest)
on 2010-10-05 19:17
(Received via mailing list)
On Tue, Oct 05, 2010 at 02:03:23PM +0900, Shyouhei Urabe wrote:
> Issue #3889 has been updated by Shyouhei Urabe.
>
> Status changed from Closed to Open
>
> Reopening.  We need a port maintainer.

I think Luis should be the port maintainer.  Luis, what do you think?
E7cff3cfd41c495e1012227d7dc24202?d=identicon&s=25 Luis Lavena (luislavena)
on 2010-10-05 20:41
(Received via mailing list)
On Tue, Oct 5, 2010 at 2:17 PM, Aaron Patterson
<aaron@tenderlovemaking.com> wrote:
> On Tue, Oct 05, 2010 at 02:03:23PM +0900, Shyouhei Urabe wrote:
>> Issue #3889 has been updated by Shyouhei Urabe.
>>
>> Status changed from Closed to Open
>>
>> Reopening.  We need a port maintainer.
>
> I think Luis should be the port maintainer.  Luis, what do you think?
>

Thank you Aaron for the vote, but I'm interested first in understand
what are the roles and duties of a port maintainer.

100% of the work done for RubyInstaller is around mingw and mingw-w64
versions of GCC, I can provide a daily test base and work on this.

However, on this same thread wanabe committed a patch I generated
which only touched mingw section of mkexports. If I has given commits
bits, I would have done the same.

I would like to understand better the roles and responsibilities
before offering myself as maintainer in the light of possible
"mistakes" I could make in the quest of a better MinGW support for
Ruby.

Thank you.
Be30361bb0b0c495e3077db43ad84b56?d=identicon&s=25 Aaron Patterson (Guest)
on 2010-10-06 04:50
(Received via mailing list)
On Wed, Oct 06, 2010 at 03:41:01AM +0900, Luis Lavena wrote:
> >
>
> Thank you Aaron for the vote, but I'm interested first in understand
> what are the roles and duties of a port maintainer.
>
> 100% of the work done for RubyInstaller is around mingw and mingw-w64
> versions of GCC, I can provide a daily test base and work on this.
>
> However, on this same thread wanabe committed a patch I generated
> which only touched mingw section of mkexports. If I has given commits
> bits, I would have done the same.

It seems to me (maybe I am wrong) that wanabe only reverted because he
is not the mingw maintainer.  As far as I can tell, nobody is.  If you
were the mingw maintainer, I think you would decide how to fix mingw
problems.

> I would like to understand better the roles and responsibilities
> before offering myself as maintainer in the light of possible
> "mistakes" I could make in the quest of a better MinGW support for
> Ruby.

I think your responsibility would be "make sure ruby works with mingw".
;-)
8cbb39dadafaf2287a83a13ee4981ec9?d=identicon&s=25 U.Nakamura (Guest)
on 2010-10-07 08:33
(Received via mailing list)
Hello,

In message "[ruby-core:32695] [Ruby 1.9-Bug#3889] Incorrectly detected
i686-w64-mingw32 as x64-mingw"
    on Oct.05,2010 23:16:07, <redmine@ruby-lang.org> wrote:
> Please apologize my lack of understanding of Ruby development hierarchy, but the revert 
of 'mingw' specifics in mkexports breaks the mingw-w64 work.

Oh, you don't have to apologize.
(And, of course, wanabe-san doesn't, too.)


> Who is the maintainer that provides "best effort" in relation to MinGW support? I would 
like to discuss this and future MinGW work without causing you guys lot of conflicts.

Agree.
The problem is not wanabe-san's revert, but a lack of responsibility
of MinGW port.

Currently, nobu is the maintainer of MinGW port.
I know him well, and everyone knows that he is the special about
hacking ruby.
However, he is not living on Windows now.
Moreover, he doesn't have 64bit Windows environment.
I guess that it is too difficult to maintain it in such situation
even if he is the special.
We should change the current state in some shape.


Regards,
E7cff3cfd41c495e1012227d7dc24202?d=identicon&s=25 Luis Lavena (luislavena)
on 2010-10-07 14:03
(Received via mailing list)
On Thu, Oct 7, 2010 at 3:33 AM, U.Nakamura <usa@garbagecollect.jp>
wrote:
> Currently, nobu is the maintainer of MinGW port.
> I know him well, and everyone knows that he is the special about
> hacking ruby.
> However, he is not living on Windows now.
> Moreover, he doesn't have 64bit Windows environment.
> I guess that it is too difficult to maintain it in such situation
> even if he is the special.
> We should change the current state in some shape.
>

Hello Mr. Nakamura,

Thank you for your answers.

I'm actively using MinGW/mingw-w64 in both native (Windows) and for
cross-compilation (Linux/OSX targeting Windows)

All the work towards 64bits Ruby under MinGW is still young, but all
the cross-compilation issues are needed right now to simplify things
for Ruby developers and their Windows support.

I'm willing to provide instructions to nobu so he can cross-compile
exactly the same way I'm doing from my OSX computer (or a Linux one,
doesn't matter)

As for the native versions, I would happily report issues and provide
patches to any encountered problem that blocks compilation or
execution, has been done already over the past years.

I will be very happy if all the existing issues for the which I
provided patches can be reviewed.

I'll happily accept become a maintainer if that is required to ensure
a proper MinGW support for Ruby.

Thank you.
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Yui NARUSE (Guest)
on 2010-12-26 06:53
(Received via mailing list)
Issue #3889 has been updated by Yui NARUSE.


What's going on?
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-12-26 21:28
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.


Hello,

The 32bits (i686-w64-mingw32) issue has been solved, and it correctly
generates i386-mingw32 as RUBY_PLATFORM

However, the 64bits version one still fails as it generates x64-mingw64
which is incorrect.

Either the platform should be 'x86_64-mingw32' or 'x64-mingw32', to
match VC x64 builds. There is an eternal discussion on mingw and
mingw-w64 mailing lists about how 'mingw32' stuck and how hard is to
change it. Usage of 'mingw64' do not correspond to any GNU triplet, as
mentioned before.

Steps to reproduce this issue:

1) Download a Linux or Darwin binaries for x86_64-w64-mingw32 from the
Automated build page:

http://sourceforge.net/projects/mingw-w64/files/To...

(I've used mingw-w64-1.0-bin_i686-linux_20101224.tar.bz2)

2) Extract into a folder:

mkdir -p ~/mingw/w64
cd ~/mingw/w64
tar xf ../mingw-w64-1.0-bin_i686-linux_20101224.tar.bz2

3) prepend 'bin' directory into the PATH:

export PATH=~/mingw/w64/bin:$PATH

4) build ruby

cd ~/ruby
autoconf
mkdir build64 && cd build64
sh ../configure --enable-shared --disable-install-doc
--host=x86_64-w64-mingw32

5) Notice the generated configuration path:

.ext/include/x64-mingw64/ruby/config.h updated

$ cat .ext/include/x64-mingw64/ruby/config.h | grep PLAT
#define RUBY_PLATFORM "x64-mingw64"

===

I'm going to attempt correct this issue but my autoconf knowledge is not
my best skill.
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2010-12-26 22:49
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.

Assigned to set to Usaku NAKAMURA

Hello,

The following patch resolves the x64-mingw64 issue described in previous
comment:

diff --git a/configure.in b/configure.in
index 3a1999c..1093a92 100644
--- a/configure.in
+++ b/configure.in
@@ -39,9 +39,7 @@ AS_CASE(["$target_os"], [mingw*msvc], [
 target_os="`echo ${target_os} | sed 's/msvc$//'`"
 ])
 AS_CASE(["$target_cpu-$target_os"], [x86_64-mingw*], [
-# canonicalize as like mswin version.  see win32/setup.mak.
 target_cpu=x64
-target_os="`echo ${target_os} | sed 's/32$/64/'`"
 ])
 ])

I would like to ask Mr. Usaku NAKAMURA to review it as mswin64 !=
mingw64, so there is no reason for canonicalize it as VC builds.

Of course, I might be missing something down the line, but will
appreciate the feedback.

Thank you.
8cbb39dadafaf2287a83a13ee4981ec9?d=identicon&s=25 U.Nakamura (Guest)
on 2010-12-27 01:33
(Received via mailing list)
Hello,

In message "[ruby-core:33911] [Ruby 1.9-Bug#3889] Incorrectly detected
i686-w64-mingw32 as x64-mingw"
    on Dec.27,2010 06:41:09, <redmine@ruby-lang.org> wrote:
> I would like to ask Mr. Usaku NAKAMURA to review it as mswin64 != mingw64, so
there is no reason for canonicalize it as VC builds.

me? not nobu?
# I am the maintainer of mswin32/mswin64, but not of mingw.

Ah, the name of port "mswin64" means that it is targeted to
use Win64 API set.
"mswin32" and "mswince" means similar.
But "mingw*" does not seem to be similar, and the meaning is
fundamentally different from the names of other platforms.
I cannot suggest any logical proposal with this state.
After all, the maintainer of this platform might draw a conclusion
according to his reason.


Regards,
E7cff3cfd41c495e1012227d7dc24202?d=identicon&s=25 Luis Lavena (luislavena)
on 2010-12-27 03:14
(Received via mailing list)
On Sun, Dec 26, 2010 at 9:33 PM, U.Nakamura <usa@garbagecollect.jp>
wrote:
> Hello,
>
> In message "[ruby-core:33911] [Ruby 1.9-Bug#3889] Incorrectly detected
i686-w64-mingw32 as x64-mingw"
>  on Dec.27,2010 06:41:09, <redmine@ruby-lang.org> wrote:
>> I would like to ask Mr. Usaku NAKAMURA to review it as mswin64 != mingw64, so
there is no reason for canonicalize it as VC builds.
>
> me? not nobu?
> # I am the maintainer of mswin32/mswin64, but not of mingw.
>

I understand, but according to the comment, canonicalize according to
mswin*, was my understanding you discussed this with Nobu.

> Ah, the name of port "mswin64" means that it is targeted to
> use Win64 API set.
> "mswin32" and "mswince" means similar.
> But "mingw*" does not seem to be similar, and the meaning is
> fundamentally different from the names of other platforms.
> I cannot suggest any logical proposal with this state.
> After all, the maintainer of this platform might draw a conclusion
> according to his reason.
>

Thank you for your observations, assigning to Nobu for approval.

Regards,
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 Luis Lavena (Guest)
on 2011-01-21 01:27
(Received via mailing list)
Issue #3889 has been updated by Luis Lavena.

Status changed from Open to Closed

This issue was solved with changeset r30620.
Luis, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

----
* configure.in: Fix incorrectly detected x86_64-w64-mingw32 due
  canonalization of target_os. Bug #3889 [ruby-core:32634]
This topic is locked and can not be replied to.