Misc #15905


[Documentation] [Request for the wiki at] - Consider adding more information to statically compiled ruby variants

Added by shevegen (Robert A. Heiler) almost 4 years ago. Updated almost 4 years ago.



Hello ruby core team in particular and other ruby folks,

This issue request here is primarily about documentation, in particular in regards to a "statically compiled
ruby". This refers either to a ruby that is completely static (no link to external .so), or, alternatively,
to a ruby that is quite small and does not need lots of stuff, a bit like mruby, but for MRI (since I use
MRI primarily, even though mruby is great). I will explain this in more detail, but first, I would like to
point to the python wiki at:

If you have a look at it then you can see specific instructions for how you can compile python statically,
such as via:

./configure LDFLAGS="-static" --disable-shared
make LDFLAGS="-static" LINKFORSHARED=" "

And some more steps before this would return the desired string "not a dynamic executable":

ldd /path/to/python
not a dynamic executable

(Oddly enough, the extra steps mentioned on that python-wiki there are a bit cumbersome; I
guess there was never any focus in python for static/embedded use per se.)

I would like to ask whether it would be possible to also add a short entry about a statically compiled
ruby, to the wiki here at I searched the wiki here, but
I was unable to find more information about statically compiling ruby.

Note that matz has already described necessary steps for statically compiled mruby variants, for example
here at github:

Which is great. I myself use MRI predominantly, though, so it would be helpful for me to have the information
available at the ruby wiki, ideally by someone who is more knowledgable than I am, and who actually knows how
to do this for it to work. I myself encountered problems, and was unable to have a statically compiled ruby;
I tried this back with an old glibc, though. (I could also use musl or other lib-c variants; I just lack the
necessary knowledge to do so on my own.)

Possibly other ruby users may also appreciate having this information available, although I assume that the
total number of ruby users who may desire or need a statically compiled ruby variant is quite low. Most people
will probably use the full MRI that is officially released every ~xmas. (I myself also prefer this ruby - it
is probably also the most widely one in use.)

My use case is mostly to have a variant of ruby that works very reliably, a bit like a statically compiled variant
of busybox (which can easily be compiled statically; if you do "make menuconfig", you can find an entry point for
static binaries, and the created busybox works well). I do not even need any extended features from ruby, such as
openssl, readline etc... - it would be nice to have this, but here I am thinking more about a ruby variant that can
be used in a "recovery" mode, or bootstrapping a new linux system . In fact, this is actually my primary use
case altogether - I am building or trying to build (again) a LFS/BLFS (linux from scratch) with some differences
to regular linux distributions. For example, I use a versioned AppDir approach rather than FHS /usr/ as the main
prefix (homebrew uses something similar, as far as I know, via /usr/Cellar or some main prefix, or something like

The way I currently do so is via a chroot(ed) environment. Since I dislike shell scripts, I actually no longer use
shell scripts really, and instead use ruby and ruby scripts for all the tasks that are required; ruby is simply
much more efficient here, from a time point of view. Also more elegant. And if necessary, I can autogenerate shell
code too, via ruby.

For a minimal environment, I think I would only need a ruby variant that can use basic file operations (such as
FileUtils), possibly system() or Io/popen too, for tapping into awk, sed, make and so forth. The latter ones can
be compiled statically and work very well. It would be great if I could complement this array of programs with
a ruby variant that would also work as a statically compiled variant, at the least for the initial bootstrap
phase (some programs will have to be recompiled in the chroot-environment, e. g. to "sanitize" the build toolchain).

In the distant future, it would be great if we could have a ruby that is super-flexible, working with the same
code base for a minimal ruby (embedded use or "recovery-mode") up towards the default MRI for everyday tasks, or
perhaps even just a ruby with like all active gems included ... fat-mode ruby. :P But I digress.

I hope I could explain my use case(s) a bit or at the least the point of view; I do not want to write that much
more, so to conclude: I would like to ask for two things specifically, as far as this issue request here is
concerned, only documentation :

  1. Please consider adding an entry to the wiki as to whether any statically compiled ruby, ideally a minimal
    variant, is possible to do: can be a simple yes or no

2a) If yes, it is possible, please also show the commandline way that was used to do this, similar to the
example of the python wiki.

2b) If it is not possible, not even any minimal ruby in a minimal environment, please mention this as well
in the documentation. A short explanation may also be helpful as to why it is not possible (I only refer
to a minimal ruby really; addons in ext/ such as readline or openssl are nice to have, but ultimately I
would not need this in a restricted/minimal environment; I mostly just need a ruby that I could use as
a replacement for bash + shell scripts, in particular for file operations and directory/symlink activities
and system(), too).

Perhaps a wiki page similar to - does not have to
be that long, just something short really. Anyway, I will finish this request here - please feel free
to disregard/close this issue request for any reason; it is admittedly not extremely important, just
would be nice to know whether it can be done, and how this could be done then. (I lack knowledge in C
to be able to know why it may work or may not work, and how to get it to work.)

Updated by naruse (Yui NARUSE) almost 4 years ago

I think the document should be in doc/ of Ruby repository.
Feel free to create a patch.

Recently our Redmine wiki is suffered by spam, and I decided to restrict the edit permission.
Therefore it's now not a suitable place for collaboration.

And also documents under doc/ is included in tarball and converted HTML and hosted by some sites.
I think it's better than our Wiki.

Updated by k0kubun (Takashi Kokubun) almost 4 years ago

  • Status changed from Open to Feedback

I think maintaining the existing documentations already exceeded our capacity and some of them are still outdated, despite of our day-to-day continuous effort. So adding a new Wiki would be a big burden. Please suggest to delete an unnecessary page instead.

A considerable amount of Ruby committers (including me) are not English-native and it's much harder to maintain various documentations for us than you imagine. Actually reading this ticket's description would take hours (so I didn't, sorry), and writing the Wiki would also take hours. The same thing just happened at

So, what I want to say is, as @naruse (Yui NARUSE) suggested, please file a pull request to put a file on! You can just suggest a structure which you want or submit a draft which misses what you don't know, and somebody could improve that on a pull request or after the commit. That helps us skip spending some time for writing the initial version and we can fix more bugs or add features by that time.

Updated by nobu (Nobuyoshi Nakada) almost 4 years ago

LINKFORSHARED means dynamically loaded extension libraries?
If so, --with-static-linked-ext configuration option makes all extension libraries linked statically (except for test libraries).
Or uncommenting the option nodynamic line in ext/Setup file does the job too.


Also available in: Atom PDF