Bug 241633
| Summary: | devel/ruby-build: 20191030 or later cannot build MRI | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Koichiro Iwao <meta> | ||||||||||
| Component: | Individual Port(s) | Assignee: | Koichiro Iwao <meta> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Only Me | CC: | meta, naito.yuichiro | ||||||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(ruby) |
||||||||||
| Version: | Latest | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| URL: | https://bugs.ruby-lang.org/issues/16331 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Koichiro Iwao
2019-11-01 05:31:29 UTC
A commit references this bug: Author: meta Date: Tue Nov 5 00:53:50 UTC 2019 New revision: 516763 URL: https://svnweb.freebsd.org/changeset/ports/516763 Log: devel/ruby-build: add a comment that mention bug 241633 PR: 241633 Changes: head/devel/ruby-build/Makefile Created attachment 208899 [details]
ruby-build.patch
I see same problem on my FreeBSD 12.1R machine with the latest ruby-build from GitHub. `rbenv install 2.6.[54]` fails as same as this PR. For a quick work around, `ruby-build.patch` fixes this problem and ruby 2.6.5 is build successfully. But I don't understand why this patch works for now. It seems BSD make's problem but compiling Ruby from tarball with BSD make was succeeded. I see same result on FreeBSD CURRENT r354344. (In reply to Yuichiro NAITO from comment #3) Above that block, it appears that ruby-build determiniing FreeBSD or not. https://github.com/rbenv/ruby-build/blob/v20191030/bin/ruby-build#L1319 I confirmed using gmake can build Ruby successfully. However, lang/ruby2[456] is built by /usr/bin/make with --enable-shared. I'm trying to find out why ruby-build + --enable-shared + /usr/bin/make fails. Created attachment 208900 [details]
whole-ruby-build-log.log
I think it's kind of race condition. BSD make with parallel build fails and BSD make with single job builds successfully. I think GNU make has different job scheduling from BSD make. One of these will solve this PR. 1. use BSD make with -j 1 2. use GNU make 3. fix dependencies in Ruby's Makefile (In reply to Yuichiro NAITO from comment #7) I'm inclined to choose 2. 3 would be a best but it doesn't take effect on past released Ruby. 1 makes build slower. Created attachment 208930 [details]
ruby-build-use-gmake
As workaround, use gmake. I'll report to Ruby and ruby-build upstream later.
Reported to Ruby upstream. A commit references this bug: Author: meta Date: Thu Nov 7 13:06:35 UTC 2019 New revision: 516970 URL: https://svnweb.freebsd.org/changeset/ports/516970 Log: devel/ruby-build: Update to 20191030 and use GNU make when building Ruby to avoid Ruby build failure. PR: 241633 Submitted by: Yuichiro NAITO <naito.yuichiro@gmail.com>, myself Sponsored by: HAW International, Inc. Changes: head/devel/ruby-build/Makefile head/devel/ruby-build/distinfo head/devel/ruby-build/files/ head/devel/ruby-build/files/patch-bin_ruby-build Committed workaround, thanks! In my investigation, There are two reasons about ruby build failure. First: It seems that it is not intended to call $(PRE_LIBRARY_UPDATE) in Ruby's Makefile, when libruby.so.26 is built. Comparing to libruby-static library build, Ruby's Makefile should be fixed like `Makefile.in.patch`. If $(PRE_LIBRARY_UPDATE) is not called, the build finished successfully. Second: $(PRE_LIBRARY_UPDATE) expands to "[ -n '' ] || exec rm -f ./.libruby-with-ext.time". The 'exec' behavior is different between with and without -j option in BSD make. With -j option, following commands after 'exec rm' are not executed. So libruby.so.26 is not build. Without -j option, following commands after 'exec rm' are executed normally. I'm not sure this behavior is a bug of BSD make. But it's enough to confuse me. Created attachment 208958 [details]
Makefile.in.patch
If this issue is fixed in upstream, MAKE_JOBS_UNSAFE=yes in lang/ruby2[456] ports should be removed and can be built parallely. Fixed in Ruby upstream: https://bugs.ruby-lang.org/issues/16331 |