Bug #7710

[mingw] r38839 breaks build

Added by Jon Forums over 1 year ago. Updated about 1 year ago.

[ruby-core:51489]
Status:Closed
Priority:High
Assignee:Nobuyoshi Nakada
Category:build
Target version:2.0.0
ruby -v:ruby 2.0.0dev (2013-01-14 trunk 38808) [i386-mingw32] Backport:

Description

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/ruby19build/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?

Associated revisions

Revision 38886
Added by Nobuyoshi Nakada about 1 year ago

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]

History

#1 Updated by Luis Lavena over 1 year ago

  • Status changed from Open to Assigned

#2 Updated by Jon Forums over 1 year ago

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?

#3 Updated by Jon Forums over 1 year ago

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#testtoolong_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\ruby19build>
c:\projects\rubyinstaller-git\sandbox\ruby19
build>exit
= 474.95 s
58) Failure:
testtoolongpath2(TestProcess) [c:/Users/Jon/Documents/RubyDev/ruby-git/test/ruby/testprocess.rb:1393]:
.
[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 testtoolongpath2
bug4315 = ''
exs = [Errno::ENOENT]
exs << Errno::E2BIG if defined?(Errno::E2BIG)
assert
raise(exs, bug4315) {Process.spawn('"a"|'10000000)}
end

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

#4 Updated by Luis Lavena over 1 year ago

  • Priority changed from Normal to Immediate

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.

#5 Updated by Shyouhei Urabe about 1 year ago

  • Priority changed from Immediate to High

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

#6 Updated by Nobuyoshi Nakada about 1 year ago

Now I suspect msys should be cross compiling.

#7 Updated by Nobuyoshi Nakada about 1 year ago

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

#8 Updated by Luis Lavena about 1 year ago

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

#9 Updated by Luis Lavena about 1 year ago

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.

#10 Updated by Nobuyoshi Nakada about 1 year ago

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

#11 Updated by Jon Forums about 1 year ago

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.

Also available in: Atom PDF