Backport #1127: error while compiling Win32API under MinGW

• Status: Closed
• Assignee: shyouhei (Shyouhei Urabe)

[luislavena (Luis Lavena)]

=begin
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:
Luis@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'
Luis@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'

 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
 

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.
=end

[snaury (Alexey Borzenkov)]

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

=begin
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.
=end

[luislavena (Luis Lavena)]

=begin
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.
=end

[luislavena (Luis Lavena)]

=begin
On Sat, Feb 7, 2009 at 1:43 PM, Roger Pack [e-mail] wrote:

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

=end

[luislavena (Luis Lavena)]

• File 001-mkmf-mingw-compatible.patch 001-mkmf-mingw-compatible.patch added

=begin
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.
=end

[snaury (Alexey Borzenkov)]

=begin
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.
=end

[luislavena (Luis Lavena)]

=begin
On Sat, Feb 7, 2009 at 5:47 PM, Alexey Borzenkov [e-mail] wrote:

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.

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.

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.

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

=end

[snaury (Alexey Borzenkov)]

=begin
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
=end

[snaury (Alexey Borzenkov)]

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

=begin
Backported my new patch to 1.8.6
=end

[snaury (Alexey Borzenkov)]

=begin
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. :)
=end

[luislavena (Luis Lavena)]

=begin
On Wed, Feb 11, 2009 at 12:20 PM, Alexey Borzenkov
[e-mail] wrote:

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

=end

[luislavena (Luis Lavena)]

=begin
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.
=end

[nobu (Nobuyoshi Nakada)]

• Category set to build
• Status changed from Open to Assigned
• Assignee set to shyouhei (Shyouhei Urabe)

=begin

=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Assigned to Closed

=begin
Applied in changeset r21749.
=end