rbenv install 3.3.4 stuck at compile localeinit.c

[Barcelus]

Hi, I'm trying to install ruby 3.3.4 on Ubuntu EC2 (Ubuntu 24.04) instance, however it keeps getting stuck at compile localeinit.c

Any idea what could be wrong?

I am extremely new to this, sorry in advance if I didn't attach something important.

[mislav]

Hi, sorry, but I have not heard of this issue before. Normally people on this discussion board are generally unable to help unless you attach a full build log, but the log file location will only get printed if the compilation encountered an error. If I understand what you are describing, your compilation process gets stuck after printing "compile localeinit.c" and does not progress from that point, nor does it print anything else until you abort the process. I can not imagine what could cause this, apart from running out of either disk space or RAM on your instance, both of which are unlikely but worth checking.

BTW, ruby-build log files can be discovered using the command ls -t ${TMPDIR:-/tmp}/ruby-build.*.log.

Make sure you prepared your Ubuntu build environment correctly using the instructions on our wiki. You could also try compiling a slightly newer patch version of Ruby 3.3, which is 3.3.6 at the time of this writing. Sometimes build bugs get fixed between patch releases. Good luck!

[Barcelus]

Hi, I kinda circumvented the problem, by installing it via ruby apt instead of rbenv.
Needed to change ruby version on my app as well, but that was not an issue.

Also, tried installing it again, this time it got stuck on a different compile (don't remember) - and since the instance is t3.micro (1GB RAM), running out of memory is plausible.

[mislav]

Ah, 1GB RAM indeed sounds very low. You could try to spin up an instance with either 2 or 4GB and see if that solves it. You could even spin up a temporary instance just to compile Ruby and then move the compiled product to an instance that has less RAM.

Installing a pre-built Ruby with your package manager is a good solution for when you just want to install Ruby without problems and when it doesn't matter that you don't get the latest released Ruby version.

[Barcelus]

Good idea - not sure if bigger instances are also free on AWS, but I'll look into it.

[mislav]

Ah, it didn't occur to me that instances of larger sizes might be cost-prohibitive. I'm sorry that this is troublesome for you. I haven't tested this myself, but it seems that on Linux it should be possible to allocate a slice of your disk space as additional RAM: https://stackoverflow.com/a/19848842. This is known as "swap partition". Note that compilation done partially using a swap partition for RAM is going to be noticeably slower (normally it should finish within ~5 minutes), but it could work in your case.

To speed up Ruby compilation, you can pass an optional flag:

rbenv install 3.3.6 -- --disable-install-doc

This skips generating offline documentation for the Ruby programming language, which can take a while even after the language interpreter itself has finished building. I myself skip this step often to speed up compilation. You can still look up Ruby language documentation online.

[Barcelus]

The swap partition thing might work, I'll give a try when I have a moment.

5 minutes - I used to leave rbenv for up to 1hr (thinking it might need that much time given specs of t3.micro instances) hoping it would unstuck itself.

[mislav]

I just tried compiling Ruby 3.3.6 in a fresh t3.micro instance and it worked within 5–10 minutes. I did not need to create a swap partition. This is the preparation I've used:

sudo apt-get install -y build-essential libssl-dev libyaml-dev zlib1g-dev libffi-dev

No extra processes were running on this instance, of course, since it was freshly made. I've kept monitoring available RAM and ruby-build pretty much used most of available RAM (the rest was used by the operating system). So if there was a server application running on this instance, however, compiling ruby would have likely failed or froze.

You can turn off parallelism when compiling by setting the MAKE_OPTS=-j1 environment variable. This overrides the -j 2 default value that would have been used since your EC2 instance technically has 2 virtual CPUs. By reducing the parallelism to 1, the compilation might take less memory, but it will likely be a bit slower.