SZJX

Unable to build Elixir with Erlang OTP 21: 'cannot get bootfile','no_dot_erlang.boot'

I’ve never built Elixir on my own and this is the first time I’ve tried to do so. However, make clean test fails with:

{"init terminating in do_boot",{'cannot get bootfile','no_dot_erlang.boot'}}
init terminating in do_boot ({cannot get bootfile,no_dot_erlang.boot})

Crash dump is being written to: erl_crash.dump...done
make: *** [lib/elixir/src/elixir_parser.erl] Fehler 1

I’m not sure what’s happening. Is it the case that Elixir was unable to find the path to the erl executable for some reason?

I was able to run erl and test it with a helloworld Erlang file just fine.

System: Kernel: 3.10.0-693.21.1.el7.x86_64 x86_64 bits: 64 gcc: 4.8.5
           Console: tty 0 Distro: Scientific Linux release 7.5 (Nitrogen)

Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

The Elixir repo is the newest master branch from Git.

7 comments

#erlang #compile #build

1 4531 7

2018-06-25 15:28:40 UTC

First 7 of 7 Posts

rlb3

This bug has been reported.

https://github.com/bitwalker/distillery/issues/426

Post #1

SZJX

Actually they’re not exactly the same issue, as Jose pointed out on the Github issue I opened. Elixir itself should still compile against OTP21.

I eventually found the problem: I installed the erlang package following an online guide, while in fact I should have installed esl-erlang package, which includes the complete package.

From the Erlang FAQ

The “esl-erlang” package is a file containg the complete installation: it includes the Erlang/OTP platform and all of its applications. The “erlang” package is a frontend to a number of smaller packages. Currently we support both “erlang” and “esl-erlang”.

I didn’t get the difference between those two packages at first sight and chose the wrong option. Apparently to successfully run Elixir you need the latter.

Thanks for pointing to the issue. That also helped to clarify the matter and point me to the right direction.

Post #2

NobbZ

Instead of installing “everything erlang related” you should have tried to figure out which of the other erlang-* packages are necessary to actually start the build, such that it can get properly documented.

Post #3

SZJX

Right. However the documentation about it is very scarce. Even when searching for the difference between these two packages there are only a lot of confusing online posts where nobody is sure. For example esl-erlang or erlang? · Issue #22 · sous-chefs/erlang · GitHub I think the official installation guide on Elixir also would result in installing the full package. Could you point to the relevant information about which packages to install?

Post #4

NobbZ

Sadly I can’t.

I’m not using one of those systems anymore where thats relevant.

For personal use, I use archlinux, where most thinks just work (while still beeing DIY when it comes to configuration).

For deployment I prefer to build systems on top of alpine when I am able to choose, where also most of the time things just work (but get really fiddly if not). Sometimes customers and clients want me to use provided service images, this is when I often just hand over precompiled binaries (no erlang/elixir so far, but go only) and let them figure out how to integrate them the best way.

Post #5

SZJX

Yeah I also use Arch personally and it’s awesome. In this project I was handed CentOS/Scientific Linux so I have no choice.

Your suggestion is sound but apparently nobody has actually spent time figuring it out. Installing the full package seems to be the default by now. Maybe it can be something that the Elixir team improves upon (in the documentation etc.) if they want. But I doubt it’ll be a priority.

Post #6

NobbZ

Well, ESL is actually third party and neither under the control of the erlang, nor of the elixir team. In the end they can change anything in any direction without telling anyone…

And if one wants to build from source, one has of course to make sure on his own, that he fullfills all of the development/build dependencies, which can differ greatly from the runtime dependencies.

I’d still hope, that the regular elixir package provided by ESL just works, so you should just use that. If it does not work, you should contact ESL and report that as a bug in their packages/repository, as it makes it unusable for elixir users.

Post #7

— All posts loaded —