Cannot install erlang 20.3.8.23

Questions / Help
1

Background

I am trying to install erlang 20.3.8.23 via asdf on my droplet so I can use an elixir server for VIM (using ALE), but unfortunately the installation is failing.

Problem

10624  CC     x86_64-unknown-linux-gnu/wxe_driver.o
10625  CC     x86_64-unknown-linux-gnu/wxe_ps_init.o
10626  CXX    x86_64-unknown-linux-gnu/wxe_main.o
10627  CXX    x86_64-unknown-linux-gnu/wxe_impl.o
10628  CXX    x86_64-unknown-linux-gnu/wxe_helpers.o
10629  CXX    x86_64-unknown-linux-gnu/wxe_callback_impl.o
10630  CXX    x86_64-unknown-linux-gnu/wxe_return.o
10631  CXX    x86_64-unknown-linux-gnu/wxe_gl.o
10632  CXX    x86_64-unknown-linux-gnu/wxe_funcs.o
10633
10634 cc1plus: out of memory allocating 65536 bytes after a total of 364257280 bytes
10635 Makefile:156: recipe for target 'x86_64-unknown-linux-gnu/wxe_funcs.o' failed
10636 make[3]: *** [x86_64-unknown-linux-gnu/wxe_funcs.o] Error 1
10637 make[3]: Leaving directory '/root/.asdf/plugins/erlang/kerl-home/builds/asdf_20.3.8.23/otp_src_20.3.8.23/lib/wx/c      _src'
10638 /root/.asdf/plugins/erlang/kerl-home/builds/asdf_20.3.8.23/otp_src_20.3.8.23/make/otp_subdir.mk:29: recipe for ta      rget 'opt' failed
10639 make[2]: *** [opt] Error 2

I understand from this log that this fails because my droplet doesn’t have enough memory. This is rather astonishing to me, as I have installed erlang 22.1 in the same machine and I didn’t have the same issue.

The other thing that jumps to my eye is the x86_64-unknown-linux-gnu. Why can’t the install figure out what version of linux I have? (is this even important?)

My droplet has the following OS:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

It has 1GB of RAM and 25GB of disk.

How can I fix this issue?

2

you can add swap so the server can “survive” the compile…

maybe erlang 22.1 is more effective during compile… did you install that using asdf as well?

after a total of 364257280 bytes

that is only ~350 mb - is something else using memory? (postgres? running beam?)

2 Likes
3

1 GiB is usually not enough to compile programs of this size. It might help but does not necessarily have to, when you force to use not more than a single compiling job. I’m not sure if asdf gives you the possibility to so though. Something comparable to makes -j flag.

Alternatively you can try to give that machine about 4 to 8 gigs of swap. If it is only for temprary use, then just using a swap file should be enough, though compiling might take forever.

The third possibility is to scale up your droplet temporary (CPU/mem only, NO disk!) and scale down after the compile job has succeeded.

And last but not least there is number 4. Use a docker image locally which is configured very closely to your droplet to build the desired version of erlang. Extract the artifacts from the resulting image and push them to the droplet such that asdf is able to find them. I’m not sure how asdf keeps track of installed versions though. If you are out of luck, you’ll need to manually edit the database file that keeps track of installed versions.

4

After reading the article and @NobbZ opinion I have opted for temporarily resizing the droptlet so as to have 4GB of RAM instead of 1GB.

If this is not enough I will consider other options, although swapping is not recommended because it can make the droplet unstable.

I have also checked the RAM usage and I can confirm that at one point during the compilation, it definitely runs out of RAM. Because the machine has no Swap, it then crashes.

I am now resizing the droplet, lets see how it goes !

5

I have resized my droplet and compiled erlang. It worked. My droplet now has 4gb of RAM and costs 4x as much.

Initially I didn’t think this was going to be an issue, after all, this is just a temporary scale up (I thought).

Unfortunately for me, as I later found out, I’m not able to downsize the droplet as the official article mentioned. I’m stuck with a droplet that will cost me 4x as much and the only thing I can do is to scp the files I want to a smaller instance, which is incredibly disappointing.

Doing so will not only take hours(which I pay for, obviously) it also requires me to know where asdf places all the releases and scp them manually.

In hindsight, resizing the droplet was a terrible mistake, I should have simply created a 3GB swap partition and let the SSD drive take the heat.

I hope my experience helps someone in the future!

1 Like
6

There’s an ASDF_CONCURRENCY variable documented, but it pretty much depends on plugins to actually use it.

7

So far I never had any problems downscaling, though I did so only a handful of times when experimenting around.

The important thing is to not resize the Harddisk, as resizing it will make the action irreversible.

8

This is actually the default mode on digital ocean. Resizing a droplet raises the disk size no matter what is you use the standard plan, which I do.

9

I tried again, I resized my 5 USD droplet to a 10 USD one, booted into it, run some random commands, powered down and resized back to a 5 USD one…

And now I will destroy this testmachine again before I get billed to much for it.

And its just as I said, “Resize CPU and RAM only” has to be choosen. For me the option with disk size included was preselected.

2 Likes
10

Did exactly the same thing, can’t resize down now. Maybe it has to do with the availability of the zone?

11

Do you need wx? If not, then pass --without-wx to configure and it will not build.

12

I don’t think I will need wx, after all this is just for a remote sever in Ubuntu. I’ll try it out, thanks !

How do I pass this option to asdf ?

(What I tried):

export KERL_CONFIGURE_OPTIONS="--without-wx"
asdf install erlang <version>

And it still fails.

With a temporary SWAP file of 4GB I was able to compile erlang 20.3.8.23. The compilation took around 2GB of RAM with the --without-wx option. Since droplets normally come with SSD disks, the compilation time was not that much longer than expected.

And the best thing here is that the SWAP file is only temporary, it goes away when you reboot the machine. Couldn’t be happier!

13

I’d only ever use asdf locally (OSX), and usually a pre-built docker image remotely, is there an issue with the erlang-solutions precompiled packages? They’re (ESL) already spending a lot of money on building/distributing.

14

The droplet in question is his “local” as the computer he got is suited even worse for developing elixir/Erlang. At least that’s how I understood this thread and an earlier one.

1 Like
15

ah understood! thanks @NobbZ

16

you understood correctly :smiley: