Issue #19289 has been updated by Eregon (Benoit Daloze). Ah, because the export list file is not given to `strip` but directly to CC/CXX: * https://github.com/redis-rb/redis-client/blob/809bbab767f8e514ccd0d6008116c3... * https://github.com/grpc/grpc/blob/a2cf991f08b32f600ddb80b4641e3da2167ae38e/s... Keeping the symbol in `RbConfig::CONFIG["STRIP"]` won't help. So that first suggestion is not going to help in practice. Instead I think we could add a clean way to detect if there is an ABI version symbol which should be preserved. For instance, setting `RbConfig::CONFIG["ruby_abi_symbol"]` to either `"rb_abi_version"` or `nil`. ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289#change-100893 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/

Issue #19289 has been updated by vo.x (Vit Ondruch). Eregon (Benoit Daloze) wrote:

the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`

Just FTR, don't forget that `ruby_version` can be arbitrary string: https://github.com/ruby/ruby/blob/90a80eb076429978e720e11fb17a3cbb96de3454/c... ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289#change-100895 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/

Issue #19289 has been updated by vo.x (Vit Ondruch). Eregon (Benoit Daloze) wrote in #note-4:

That said this kind of configuration is IMHO silly, changing it is basically guaranteed to break things, so a better way would be remove such configuration

I think it was always meant to allow to install multiple versions of the same version of Ruby, with possibly different configuration and what not. Unfortunately, the name is not always not expressive enough and not all Ruby maintainers know/remember why this variable is there and therefore it might be misunderstood/misused. BTW I historically proposed to allow the `ruby_version` to not be used at all, e.g. to be an empty string. This unfortunately have not worked out. Instead, the `ruby_version` was made mandatory :/ And we still carry this patch in Fedora: https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby-2.3.0-ruby_versi... and here is relevant PR: https://github.com/ruby/ruby/pull/2392 ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289#change-100903 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/

Issue #19289 has been updated by naruse (Yui NARUSE). Backport changed from 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONE ruby_3_2 4110137fcfd805de03a8f5569c3d6926959b9363 merged revision(s) 6f3aff3961a4c5ce87e05096a1a9dcf1055b7647. ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `ruby_abi_version` and `ruby_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289#change-101453 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONE ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/