[RbConfig] add RUBY_SO_NAME and RUBY_BASE_NAME

[ahorek]

this is a part of https://github.com/jruby/jruby/pull/5948/files#diff-07a392f8a3701f33b114e2bd8487c7a7R132

#5948

[headius]

Cherry-picked to update_ffi in eeb3f6f and 843067e.

What does this really mean for JRuby, though? We don't have a .so, so I assume this is not actually used when running specs.

[ahorek]

you're absolutely right, in JRuby RUBY_SO_NAME is a fake value, but the new FFI code use it to determine a GLIBC path

RbConfig::CONFIG['RUBY_SO_NAME'].split('-')[-2] + '.dll'
=> msvcrt.dll

is there a better way how to detect the right path? maybe we should fix it the ffi gem instead

[headius]

Ahh ok, I understand now.

The C library on Windows will presumably always be the same filename, perhaps with a 64 indicator added to it. The C library on other platforms will vary.

I guess this is really only used on Windows? On my MacOS system, there's nothing in this value to indicate the libc name:

$ rvm ruby-2.6.5 do ruby -e 'p RbConfig::CONFIG["RUBY_SO_NAME"]'
"ruby.2.6"

[ahorek]

for some reason, the C library seems to be always compiled statically on Windows.

there's a similar hack in fiddle
https://github.com/ruby/ruby/blob/master/test/fiddle/helper.rb#L47

I think there're two real options
UCRTBASE.DLL for visual studio binaries
MSVCRT.DLL for mingw (GCC)

https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL

[ahorek]

you probably can't combine different C libraries together. I'm guessing that's why they did it that way, something like GLIBC vs MUSL issues on Linux...

[ahorek]

another example from the jnr-posix library
https://github.com/jnr/jnr-posix/blob/94eb55e2397a8b01188eb3bfad3f2b22163a3713/src/main/java/jnr/posix/POSIXFactory.java#L199

private static String[] libraries() {
          case WINDOWS:
              return new String[] { "msvcrt", "kernel32" };
....

there's just "msvcrt"...