[#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:100997] [Ruby master Bug#17337] Don't embed Ruby build time configuration into Ruby
From:
shyouhei@...
Date:
2020-11-21 05:01:22 UTC
List:
ruby-core #100997
Issue #17337 has been updated by shyouhei (Shyouhei Urabe). This is a tough problem. Ruby ships several hundreds of C/C++ header files (those under `include/` in our distribution). 3rd party extension libraries are expected to include them. The problem is, there are header files which depend on _runtime_ API/ABI detected by our configure script. For an example we choose one of our 3 distinct `select(2)` wrapper depending on how many file descriptor the system can take at once. If the header file does not agree with generated ruby binary whatever bad thing can happen. As for C++ compilers, we want to know the availability of `std::nullptr_t`. If there is that type we provide extra function overloads that prevent warnings around casts. The particular C++ feature detection business, I guess, could be possibly delayed until people configure their extension library. C++ nowadays are largely header-only. But if you want to separate the entire environment between the core and the extensions, I honestly have no idea if that is even possible. ---------------------------------------- Bug #17337: Don't embed Ruby build time configuration into Ruby https://bugs.ruby-lang.org/issues/17337#change-88664 * 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 build without C++ compiler available, subsequent builds of the Eventmachine extensions (or any other gem which requires C++ compiler) fails: ~~~ ... 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 don't like to question 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 the Ruby is built might be different to the machine where Ruby is used and the extension is installed. The typical example is every binary Linux distribution. But also RVM is using precompiled Ruby binaries if I am not mistaken. Therefore I would appreciate if embedding Ruby build time configuration into Ruby and its reusing for Ruby extension build is reconsidered. This would help to avoid the issue of Eventmachine I started with, but also avoid the issues such as #14422 Just FTR, to avoid this kind of issues, as a Ruby maintainer on Red Hat plaforms, I am considering to ship rbconfig.rb in vendorlib, which would dynamicaly 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>