Bug #7710
closed[mingw] r38839 breaks build
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/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?
Updated by luislavena (Luis Lavena) over 9 years ago
- Status changed from Open to Assigned
Updated by jonforums (Jon Forums) over 9 years 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?
Updated by jonforums (Jon Forums) over 9 years 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#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.
Updated by luislavena (Luis Lavena) over 9 years ago
- 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.
Updated by shyouhei (Shyouhei Urabe) over 9 years ago
- Priority changed from 7 to 5
Hi, I know it's important, but wanna decrease its priority because it seems build finishes.
Updated by nobu (Nobuyoshi Nakada) over 9 years ago
Now I suspect msys should be cross compiling.
Updated by nobu (Nobuyoshi Nakada) over 9 years 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] [ruby-core:51489]
Updated by luislavena (Luis Lavena) over 9 years 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:
Updated by luislavena (Luis Lavena) over 9 years 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.
Updated by nobu (Nobuyoshi Nakada) over 9 years 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.
Updated by jonforums (Jon Forums) over 9 years 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.