From: shyouhei@... Date: 2020-11-24T01:08:57+00:00 Subject: [ruby-core:101033] [Ruby master Bug#17337] Don't embed Ruby build-time configuration in Ruby Issue #17337 has been updated by shyouhei (Shyouhei Urabe). vo.x (Vit Ondruch) wrote in #note-7: > However, I don't think that embedding of the compile time options addresses any of these concerns. If they should be addressed, that would mean to do the same configuration checks once done for Ruby also for build of extensions and fail the build if they differs. Right. I'm not saying we are doing well. Rather I say there is a headache. Ruby had already assumed the exact same runtime environment for both core & extensions. You want to separate them. I understand your motivation. But... that is harder than it sounds. > Also, I don't really know, what component is responsible for number of file descriptors, but on Linux, I'd assume this is Kernel. But if the value is changed in between kernel versions, then the compile time choice of `select(2)` might not be optimal. That would happen. We have experienced situations like for instance getrandom(2) system call already implemented in the Kernel, but not yet available in glibc. Luckily that did not affect extension libraries though. vo.x (Vit Ondruch) wrote in #note-8: > shyouhei (Shyouhei Urabe) wrote in #note-5: > > JFYI because compilers tend to LTO these days, libruby can be a compiler-specific internal representation of the entire source code, not an archive of object files. If that is the case, people cannot use arbitrary C++ compiler. It must exactly match the C compiler used to generate libruby. Detection of such things could be done in mkmf.rb I guess, but not as easy as to ���move��� the current logic. > > This sounds that this applies to statically linked Ruby, or does it apply to shared libruby as well? I care just about the later if that makes any difference. AFAIK no dynamic linker interfaces with compilers' LTO facilities. ---------------------------------------- Bug #17337: Don't embed Ruby build-time configuration in Ruby https://bugs.ruby-lang.org/issues/17337#change-88704 * 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: