From: v.ondruch@... Date: 2020-11-24T22:32:35+00:00 Subject: [ruby-core:101059] [Ruby master Bug#17337] Don't embed Ruby build-time configuration in Ruby Issue #17337 has been updated by vo.x (Vit Ondruch). Eregon (Benoit Daloze) wrote in #note-11: > vo.x (Vit Ondruch) wrote in #note-10: > > 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. > > I disagree with that, specifically, C/C++/native extensions should rely on configuration from Ruby libraries such as `mkmf` and `RbConfig`. I don't think I have anything specifically against `mkmf`. It is fine by me if it can be utilized. However, reusing embedded values from RbConfig is not always the best idea. > FWIW TruffleRuby detects most things at runtime, and having a given fixed toolchain avoids so many of these headaches, which e.g. makes it possible to have a single prebuilt Linux binary running on all distributions, with the exception that the openssl C extension is recompiled on the runtime system at installation time because libssl varies too much per platform. Given the above mentioned relation between Kernel and Ruby build configurations, that leads me to believe that TruffleRuby is doing fine for most of the cases, but there are probably some corner cases. And similar situation is probably on Red Hat platforms. Also, believe me that if you are using Fedora/RHEL provided libraries, you are basically in the same situation as you described the situation of TruffleRuby. But since we still want our users allow to use `gem install`, then I have to care also about these situations. ---------------------------------------- Bug #17337: Don't embed Ruby build-time configuration in Ruby https://bugs.ruby-lang.org/issues/17337#change-88731 * 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: