Bug #7710: [mingw] r38839 breaks build

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: 2.0.0
• ruby -v: ruby 2.0.0dev (2013-01-14 trunk 38808) [i386-mingw32]

[jonforums (Jon Forums)]

On my Win7 32bit system using mingw-w64 gcc 4.7.2 and the RubyInstaller build recipes I get the following failure

make[2]: Entering directory /c/projects/rubyinstaller-git/sandbox/ruby19_build/ext/ripper' extracting ripper.y from ../../../../../../Users/Jon/Documents/RubyDev/ruby-git/parse.y id.h not found in ["..\\..\\..\\..\\..\\..\\Users\\Jon\\Documents\\RubyDev\\ruby-git\\ext\\ripper;..\\..;..\\..\\.ext\\include\\i386-mingw32\\ruby;..\\..\\..\\..\\..\\..\\Users\\Jon\\Documents\\RubyDev\\ruby-git\\include\\ruby;..\\..;..\\..\\..\\..\\..\\..\\Users\\Jon\\Documents\\RubyDev\\ruby-git"] make[2]: *** [ripper.y] Error 1 make[2]: Leaving directory /c/projects/rubyinstaller-git/sandbox/ruby19_build/ext/ripper'
make[1]: *** [ext/ripper/all] Error 2
make[1]: Leaving directory `/c/projects/rubyinstaller-git/sandbox/ruby19_build'
make: *** [build-ext] Error 2

due to id.h not being found.

The same failure is occurring on the RubyInstaller CI: http://ci.rubyinstaller.org/job/ruby-trunk-x86-build/820/console

While placing id.h in ext/ripper enabled a successful rebuild, havoc reigned during make test-all. Reverting r38839 fixed the issue.

FWIW, in both the passing and failing cases my rbconfig.rb contains

CONFIG["PATH_SEPARATOR"] = ":"

I won't have time to play with configure.in to see if changing the separator to ";" on mingw will also fix the issue, but I'm sceptical given the test-all failures.

As previous *nix and win7 builds were fine, why was this change needed?

[luislavena (Luis Lavena)]

• Status changed from Open to Assigned

[jonforums (Jon Forums)]

I see test-all failures after reverting r38839; trying a fresh build to see if it's a red-herring.

Luis or Hiroshi...can you repro?

[jonforums (Jon Forums)]

With a fresh Win7 build, reverting r38839 fixes the build, make test is OK, but make test-all stumbles over the cliff in

[ 7987/13078] TestProcess#test_too_long_path2

by exiting sh (msys) into cmd.exe. Oddly, typing exit from cmd.exe (eh??) returns you back to sh, gives the following failure

c:\projects\rubyinstaller-git\sandbox\ruby19_build>
c:\projects\rubyinstaller-git\sandbox\ruby19_build>exit
= 474.95 s
58) Failure:
test_too_long_path2(TestProcess) [c:/Users/Jon/Documents/RubyDev/ruby-git/test/ruby/test_process.rb:1393]:
[ruby-core:34833].
[Errno::ENOENT, Errno::E2BIG] expected but nothing was raised.

and continues running tests until finishing with

Finished tests in 1319.324032s, 9.9127 tests/s, 1591.9213 assertions/s.
13078 tests, 2100260 assertions, 2 failures, 2 errors, 96 skips

ruby -v: ruby 2.0.0dev (2013-01-17 trunk 38864) [i386-mingw32]
make: *** [yes-test-all] Error 4
sh-3.1$

Here's TestProcess#test_too_long_path2

def test_too_long_path2
bug4315 = '[ruby-core:34833]'
exs = [Errno::ENOENT]
exs << Errno::E2BIG if defined?(Errno::E2BIG)
assert_raise(*exs, bug4315) {Process.spawn('"a"|'*10_000_000)}
end

On Arch 3.6.11 with r38839 reverted: build OK, make test OK, and make test-all completes with 4 (unrelated?) failures.

[luislavena (Luis Lavena)]

• Priority changed from Normal to 7

Hello Nobu,

We didn't get a response about this from you.

Please let us know if you can solve this or that we should revert such change.

Thank you.

[shyouhei (Shyouhei Urabe)]

• Priority changed from 7 to 5

Hi, I know it's important, but wanna decrease its priority because it seems build finishes.

[nobu (Nobuyoshi Nakada)]

Now I suspect msys should be cross compiling.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

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

---

vpath.rb: hack for msys make

• tool/vpath.rb (VPath#def_options): hack for msys make, which
  converts a command line argument to non-msys command seems like a
  path list automagically. [Bug #7710] [ruby-core:51489]

[luislavena (Luis Lavena)]

shyouhei (Shyouhei Urabe) wrote:

Hi, I know it's important, but wanna decrease its priority because it seems build finishes.

Urabe-san, the first build that passed was 30 minutes ago, it was broken for many builds:

http://ci.rubyinstaller.org/view/All/builds

[luislavena (Luis Lavena)]

nobu (Nobuyoshi Nakada) wrote:

Now I suspect msys should be cross compiling.

I don't understand this but thank you for fixing it.

I assume this could affect cross-compilation of Ruby? I'll try and report back.

[nobu (Nobuyoshi Nakada)]

I meant that we should use msys-native ruby as BASERUBY instead of built miniruby, but seems msys doesn't provide its native ruby.

[jonforums (Jon Forums)]

Thank you nobu-san.

Win7 32bit

build: PASS
make test: PASS
make test-all: 2 FAILS, #7276 and TestProcess#test_too_long_path2 (new issue) mentioned above

Arch 3.6.11 32bit

build, make test, make test-all: PASS

Ubuntu Server 12.10 64bit

build, make test, make test-all: PASS

I will create a new issue for TestProcess#test_too_long_path2 later today. Odd that it's not also failing at ci.rubyinstaller.org

re: potentially using msys-native ruby as BASERUBY rather than build miniruby, this will not work well with the existing rubyinstaller build recipes because the msys environment is not usually persistent. Meaning, msys+mingw are typically extracted into a temp sandbox dir and only used for the build. The sandbox dir is usually deleted after each build. For example, when I build on Win7 32bit I create a 800MiB ramdisk (via imdisk) holding the temp sandbox build dir.