Python and Ruby link dynamically by default from the executable of the runtime to the runtime library. Most runtimes do that, it is a good design that allows reusing the runtime to the embedders. As exception of NodeJS which avoids this because of a design decision related to the distribution, and because it hasn't got an embedding API and an stable extension API (N-API) until 8.x, and Rust, due to lack of ABI stability.

I didn't check GHC and Java yet, but most languages that have extension and mainly embedding API do that (JVM has embedding and extension API).

I am not an expert about Guile but I can  check the configure/Makefile of Ruby in order to see what flags do it need to compile against the dynamic library, and providing the static too as Debian distribution does for Ruby (or Guix itself for Python and libpython3.7m.so).

El sáb., 7 dic. 2019 17:44, Brett Gilio <brettg@posteo.net> escribió:

Vicente Eduardo <vic798@gmail.com> writes:

> I would like to have two versions, or at least the dynamic one, that's the common way
> Ruby should be built, and also the Guixy style.

This actually brings up a rather interesting point. What is the Guix
protocol on compilation for dynamic vs statically linked interpreters?
This is a prevalent issue not just for Ruby, but for also how we handle
GHC, Rust, JDK, and so on.

Generally, I think we dynamically link most objects. _BUT_, I could be
missing part of the story here. So I am going to wait for the higher
powers that be to respond.

In the mean time, when I get a moment, I will do some auditing on this
package to see if the issue is just that we are missing some compilation
procedure. Hopefully it is just as simple as that, but I still think the
issue of linkage style (dynamic vs static linkage) remains prevalent.

Hopefully we hear some noise on this soon.

--
Brett M. Gilio
https://git.sr.ht/~brettgilio/