[#100689] [Ruby master Feature#17303] Make webrick to bundled gems or remove from stdlib — hsbt@...
Issue #17303 has been reported by hsbt (Hiroshi SHIBATA).
11 messages
2020/11/02
[#100852] [Ruby master Feature#17326] Add Kernel#must! to the standard library — zimmerman.jake@...
SXNzdWUgIzE3MzI2IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGpleiAoSmFrZSBaaW1tZXJtYW4pLg0K
24 messages
2020/11/14
[#100930] [Ruby master Feature#17333] Enumerable#many? — masafumi.o1988@...
Issue #17333 has been reported by okuramasafumi (Masafumi OKURA).
10 messages
2020/11/18
[#101071] [Ruby master Feature#17342] Hash#fetch_set — hunter_spawn@...
Issue #17342 has been reported by MaxLap (Maxime Lapointe).
26 messages
2020/11/25
[ruby-core:101044] [Ruby master Bug#17337] Don't embed Ruby build-time configuration in Ruby
From:
v.ondruch@...
Date:
2020-11-24 09:20:50 UTC
List:
ruby-core #101044
Issue #17337 has been updated by vo.x (Vit Ondruch). shyouhei (Shyouhei Urabe) wrote in #note-9: > Ruby had already assumed the exact same runtime environment for both core & extensions. While considering everything what was said here, this is not surprise. Nevertheless, I am not sure this is wildly known and documented enough. However, in Red Hat ecosystem, this was never true. Build of Ruby RPM always happens on different system then build of RubyGems RPM packages. The configuration of the runtime system is certainly different from the builders. The underlying Kernel can change including changing important defaults. Using Ruby in containers, there is not enough information about undrlying Kernel, one cannot even rely on kernel-headers, because they very likely don't match. Discussing #16694 with RH toolchain folks, I was even suggested to use CLang to build Ruby itself, while keep using GCC to build extensions. Therefore, given the real world use cases, isn't it time to reconsider this? I understand I'm leaving a lot of technical "details" aside, but if I could come in this case to Eventmachine upstream and say "you should not rely on Ruby detected configuration, do your own detection for best results, because Ruby upstream acknowledges the build time and runtime environment might differ", I'd be certainly in better place. ---------------------------------------- Bug #17337: Don't embed Ruby build-time configuration in Ruby https://bugs.ruby-lang.org/issues/17337#change-88715 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.0dev (2020-11-04 master 704fb0b815) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- When Ruby 3.0 is built without C++ compiler available, subsequent builds of Eventmachine extensions (or any other gems that require C++ compiler) fail: ~~~ ... snip ... "make \"DESTDIR=\"" I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -m64 -o binder.o -c binder.cpp make: I.: No such file or directory make: [Makefile:237: binder.o] Error 127 (ignored) ~~~ This happens since [1]. I would like to question not just the commit, but the whole principle. Availability of C++ compiler during build of Ruby does not have anything to do with availability of C++ compiler during build of whatever Ruby extension. Moreover, the machine where Ruby is built might be different from the machine where Ruby is used and the extension is installed. Typical examples are binary Linux distributions. RVM also uses precompiled Ruby binaries if I am not mistaken. Therefore, I would appreciate if we reconsider embedding Ruby build-time configuration in Ruby and reusing it for Ruby extension build. This would solve the issue of Eventmachine I started with, and also issues such as #14422 Just FTR, to avoid this kind of issues, as a Ruby maintainer on Red Hat platforms, I am considering to ship rbconfig.rb in vendorlib, which would dynamically fix these issues. E.g. set the `CONFIG['CXX']` based on C++ compiler availability during extension build. But I'd like to avoid it, at least as a downstream modification. [1]: https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>