Discussion:
[ruby-core:21903] [Bug #1127] error while compiling Win32API under MinGW
(too old to reply)
Luis Lavena
2009-02-07 02:58:21 UTC
Permalink
Bug #1127: error while compiling Win32API under MinGW
http://redmine.ruby-lang.org/issues/show/1127

Author: Luis Lavena
Status: Open, Priority: Normal
Target version: Ruby 1.8.6
ruby -v: ***@KEORE (D:\Users\Luis\projects\oss\oci\dsl2\sandbox\ruby\1.8.6-svn\build) $ ruby -v ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]

I've been trying to build both p287 and svn branch using MinGW:

gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
autoconf (GNU Autoconf) 2.61
GNU Make 3.81 (cpmake and csmake)

Subversion information:
***@KEORE (D:\Users\Luis\projects\oss\oci\dsl2\sandbox\ruby\1.8.6-svn\build)
$ svn info ..\source
Path: ..\source
URL: http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6
Repository Root: http://svn.ruby-lang.org/repos/ruby
Repository UUID: b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Revision: 22102
Node Kind: directory
Schedule: normal
Last Changed Author: shyouhei
Last Changed Rev: 22065
Last Changed Date: 2009-02-04 22:38:22 -0200 (Wed, 04 Feb 2009)

Configure options:
../source/configure --enable-shared --disable-install-doc --with-winsock2 --prefix=/

Last lines of 'make'
***@KEORE (D:\Users\Luis\projects\oss\oci\dsl2\sandbox\ruby\1.8.6-svn\build)
$ ..\..\..\msys\1.0.11\source\bin\sh.exe -login -c 'make'

<pre><code>
gcc -g -O2 -DRUBY_EXPORT -L. -Wl,--stack,0x02000000 main.o dmydln.o libmsvcrt-ruby18-static.a -lshell32 -lws2_32 -o miniruby.exe
rbconfig.rb updated
windres --include-dir . --include-dir . --include-dir ../source/win32 msvcrt-ruby18.rc msvcrt-ruby18.res.o
gcc -shared -s -Wl,--enable-auto-image-base,--enable-auto-import,--export-all -Wl,--out-implib=libmsvcrt-ruby18.dll.a array.o bignum.o class.o compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o fileblocks.o crypt.o flock.o win32.o dmyext.o msvcrt-ruby18.res.o -lshell32 -lws2_32 -o msvcrt-ruby18.dll
Creating library file: libmsvcrt-ruby18.dll.a
-e:2: syntax error, unexpected tSTRING_BEG, expecting $end
compiling Win32API
make[1]: Entering directory `/d/Users/Luis/projects/oss/oci/dsl2/sandbox/ruby/1.8.6-svn/build/ext/Win32API'
mkdir -p ../../.ext/i386-mingw32
make[1]: *** No rule to make target `Win32API.c', needed by `Win32API.o'. Stop.
make[1]: Leaving directory `/d/Users/Luis/projects/oss/oci/dsl2/sandbox/ruby/1.8.6-svn/build/ext/Win32API'
make: *** [all] Error 1
</code></pre>

Both p287 and svn checkout fail in the same place.

Historically, the only way I could build ruby is using make 2.79, 2.81 always fail.

1.9.1-p0, on the other hand, build successfuly

See attached both configure output and make full output.

Thank you.


----------------------------------------
http://redmine.ruby-lang.org
Alexey Borzenkov
2009-02-07 07:55:36 UTC
Permalink
Issue #1127 has been updated by Alexey Borzenkov.

File 0003-Allow-building-ruby-with-mingw.patch added

Luis, you would need something like this patch to build it with make 3.81. This patch is against 1.8.7, but should be easy to port to 1.8.6. I have previously posted a similar patch to ruby-core, and this is a slightly improved version.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Luis Lavena
2009-02-07 15:35:33 UTC
Permalink
Issue #1127 has been updated by Luis Lavena.


Thank you Alexey,

I'm going to use this patch and see what happens. It bothers me that 1.9 *can* compile with make 2.81.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Roger Pack
2009-02-07 15:43:19 UTC
Permalink
Post by Luis Lavena
Bug #1127: error while compiling Win32API under MinGW
Creating library file: libmsvcrt-ruby18.dll.a
-e:2: syntax error, unexpected tSTRING_BEG, expecting $end
If it's any help, this error looks vaguely similar to the errors I
sometimes get running ruby mingw -e with quotes on the command line.
Thanks for looking into this.
-=r
Luis Lavena
2009-02-07 17:00:45 UTC
Permalink
Post by Roger Pack
Post by Luis Lavena
Bug #1127: error while compiling Win32API under MinGW
Creating library file: libmsvcrt-ruby18.dll.a
-e:2: syntax error, unexpected tSTRING_BEG, expecting $end
If it's any help, this error looks vaguely similar to the errors I
sometimes get running ruby mingw -e with quotes on the command line.
Thanks for looking into this.
Quotes in the prompt is something else, -e is not part of this error.

Looks like r21829 in 1_9_1 merged r21749 and r21750 from trunk (commit by yugui)

There is a chance to backport those into 1_8_6?
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Luis Lavena
2009-02-07 17:33:12 UTC
Permalink
Issue #1127 has been updated by Luis Lavena.

File 001-mkmf-mingw-compatible.patch added

Thank you Alexey!

I've just created a backport of your patch that applies directly in 1.8.6-p287 and 1_8_6 branch

OT: Since you're using MinGW and Ruby, are interested in contribute to RubyInstaller project? Just a thought.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Alexey Borzenkov
2009-02-07 19:47:20 UTC
Permalink
Issue #1127 has been updated by Alexey Borzenkov.


Hi Luis,

I see you based your backport on old patch I posted to ruby-core, that's unfortunate. :-/ I think quote_for_make is working really better, but oh well, it's your and everyone else's choice.

Also, I remember there was some other bug about ruby.h not being found, which Matz fixed in http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=21783 - in my opinion it doesn't cut the real root of the problem, but who am I and who are they... maybe it does it for you.

I don't know if you were trying to build 1.9 trunk or what, but when I was trying some version of 1.9 I remember I still needed to apply my patches, so it's very strange how you didn't encounter this same error... Unfortunately I can't really test it now, since I switched to Mac at home. Maybe at work on Monday, if I have time I'll look what the situation is with 1.9.1 and trunk.

P.S. People in ruby world don't seem to use mingw much, makes me wonder which key people are still using Visual Studio 6.0 for the situation to stagnate so much. :( I really hope for mingw-based RubyInstaller to change the balance, that would make ruby much more viable platform on Windows.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Luis Lavena
2009-02-07 19:56:43 UTC
Permalink
Post by Alexey Borzenkov
Issue #1127 has been updated by Alexey Borzenkov.
Hi Luis,
I see you based your backport on old patch I posted to ruby-core, that's unfortunate. :-/ I think quote_for_make is working really better, but oh well, it's your and everyone else's choice.
I've tried to apply your patch, but didn't work as expected, so since
1.9.1 branch built properly I took that commit as reference.

Don't take my call as something personal, I tried something that
worked now, but maybe is set to failure in the long run. I just built
it, cannot comment too much.
Post by Alexey Borzenkov
Also, I remember there was some other bug about ruby.h not being found, which Matz fixed in http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=21783 - in my opinion it doesn't cut the real root of the problem, but who am I and who are they... maybe it does it for you.
So far it worked, but again, that's another bug that should be
backported from 1.9 to 1.8

Saw that change too, but that's something I'll tackle when time allows.
Post by Alexey Borzenkov
I don't know if you were trying to build 1.9 trunk or what, but when I was trying some version of 1.9 I remember I still needed to apply my patches, so it's very strange how you didn't encounter this same error... Unfortunately I can't really test it now, since I switched to Mac at home. Maybe at work on Monday, if I have time I'll look what the situation is with 1.9.1 and trunk.
You can try to build it with mingw macports installed and
rake-compiler: (cross-ruby) task.
Post by Alexey Borzenkov
P.S. People in ruby world don't seem to use mingw much, makes me wonder which key people are still using Visual Studio 6.0 for the situation to stagnate so much. :( I really hope for mingw-based RubyInstaller to change the balance, that would make ruby much more viable platform on Windows.
They build ruby under cygwin environment, not MSYS. The VC6 dependency
is indeed old, but who am I to criticize it? Tried several times get
in touch and help out on that topic without answers, so I'm doing my
own way.

Right now working on mingw-based RubyInstaller, let's see how that ends.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Alexey Borzenkov
2009-02-07 20:54:09 UTC
Permalink
Issue #1127 has been updated by Alexey Borzenkov.


Luis, actually no, all of these bugs are the very same, and that's VPATH variable semantics. Matz fixes just one manifestation, but not the root of the problem. When my patch is applied, you don't need to backport his change to 1.8, as all primary variables will contain correct paths anyway, and VPATH will work.

Before make 3.81 msys was happily accepting ';' as a separator, but now suddenly it does not, perhaps because msys (as small as it) is a unix emulation layer, and unix uses ':' as path separator, so VPATH mkmf provides is broken. My patch fixes primary and VPATH variables generation, which is easy when you are building ruby itself, but gets more complicated when building extensions.

If my patch was just to build ruby, it would simply use ':' as VPATH separator, because when building ruby itself VPATH contains relative paths only. But then we install it somewhere, and our config.rb will contains full path to installed ruby (something like C:\Ruby\...), and suddenly, when building extensions, a new problem arises, and it's invalid paths.

I haven't tested it thoroughly, but something like C:\Ruby\lib\...:C:\Ruby\... in VPATH just won't fly, that's why we need to convert paths that msys would understand. There's relevant code for cygwin, that uses cygpath to convert paths. Unfortunately there's no such utility for msys, thus mkmf needs to do it "by hand".

I'm surprised that my new patch didn't work for you though, maybe it was messed up when I uploaded it. You can see it here: http://git.kitsu.ru/patched/ruby-1.8.git?a=commitdiff;h=38383575ab3244bb62362956a43994a0953db37e

P.S. Cross compiling it doesn't make sense, because this problem only happens with native msys with recent versions of msys-make. :) So I'd need either Windows or wine with installed msys and mingw to test it... x_x
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Alexey Borzenkov
2009-02-07 21:40:01 UTC
Permalink
Issue #1127 has been updated by Alexey Borzenkov.

File 0001-Allow-building-ruby-with-mingw.patch added

Backported my new patch to 1.8.6
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Alexey Borzenkov
2009-02-11 14:20:05 UTC
Permalink
Issue #1127 has been updated by Alexey Borzenkov.


Whoa, just when I was starting to move to 1.9.1, and downloaded -p0, I found that it already contains mkintpath. So, sorry for all I said earlier, everything's cool in 1.9 land. :)
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Luis Lavena
2009-02-11 19:23:05 UTC
Permalink
On Wed, Feb 11, 2009 at 12:20 PM, Alexey Borzenkov
Post by Alexey Borzenkov
Issue #1127 has been updated by Alexey Borzenkov.
Whoa, just when I was starting to move to 1.9.1, and downloaded -p0, I found that it already contains mkintpath. So, sorry for all I said earlier, everything's cool in 1.9 land. :)
That's what I said and that what I've attached to the ticket for backport :-D
(001-mkmf-mingw-compatible.patch)

Thank you Alexey for your time.

Ruby 1.8 maintainers: there is a chance get that backported to 1.8?

Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Luis Lavena
2009-03-21 19:07:30 UTC
Permalink
Issue #1127 has been updated by Luis Lavena.


Bumping this up again,

Anyone can apply the patch before the new 1.8.6 get released? Or at least backport the fix from 1.9.1 into it.

There is no way, using MinGW+MSYS to build Ruby 1.8.6.

Thank you.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org
Shyouhei Urabe
2009-04-08 10:07:08 UTC
Permalink
Issue #1127 has been updated by Shyouhei Urabe.

Status changed from Assigned to Closed

Applied in changeset r21749.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1127

----------------------------------------
http://redmine.ruby-lang.org

Roger Pack
2009-02-08 04:45:17 UTC
Permalink
Post by Alexey Borzenkov
Also, I remember there was some other bug about ruby.h not being found, which Matz fixed in http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=21783 - in my opinion it doesn't cut the real root of the problem, but who am I and who are they... maybe it does it for you.
I use msys and would also be quite happy if it were more strongly supported :D
Mingw for me runs nicely on windows--far faster than msvc 6. [1]
Thanks for your help.
-=r
[1] http://groups.google.com/group/ruby-benchmark-suite/browse_thread/thread/b30155e85bb77bfe
Loading...