Cannot start sample erlang release generated with rebar - erlang

Question

I'm a beginner with rebar and erlang generally. I was trying to create an erlang release with rebar according to this tutorial: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades and got stuck at the point of running generated release.
My system is Ubuntu 11.04 64bit, erlang R14B03, installed from sources.
When i'm invoking 'bin/somenode console', I get one of the following errors:
Exec: /home/ghik/Inz/somerel/rel/somenode/erts-5.8.4/bin/erlexec -boot /home/ghik/Inz/somerel/rel/somenode/releases/1/somenode -mode embedded -config /home/ghik/Inz/somerel/rel/somenode/etc/app.config -args_file /home/ghik/Inz/somerel/rel/somenode/etc/vm.args -- console
Root: /home/ghik/Inz/somerel/rel/somenode
{"init terminating in do_boot",{'cannot load',hipe_amd64_encode,get_files}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
Interestingly, each time I run it, different atom is listed instead of 'hipe_amd64_encode', for example: 'hipe_amd64_defuse', 'hipe_amd64_assemble', etc.
I'm guessing erlang is unable to load hipe, but I have no idea why is is trying to load it in the first place. The release contains only one, very simple application dependent only on kernel and stdlib.
For some reason, rebar generates a .rel file with lots of unnecessary applications:
%% rel generated at {2011,9,6} {20,5,48}
{release,{"somenode","1"},
{erts,"5.8.4"},
[{kernel,"2.14.4"},
{stdlib,"1.17.4"},
{sasl,"2.1.9.4"},
{someapp,"1"},
{compiler,"4.7.4",load},
{crypto,"2.0.3",load},
{et,"1.4.3",load},
{gs,"1.5.13",load},
{hipe,"3.8",load},
{inets,"5.6",load},
{mnesia,"4.4.19",load},
{observer,"0.9.9",load},
{public_key,"0.12",load},
{runtime_tools,"1.8.5",load},
{ssl,"4.1.5",load},
{syntax_tools,"1.6.7.1",load},
{tools,"2.6.6.4",load},
{webtool,"0.8.8",load},
{wx,"0.98.10",load}]}.
Why does rebar list soo many applications in the .rel file? And event if it's fine, why doesn't the release start?

Answer 1

Add to reltool.config, the following line:
{app, hipe, [{incl_cond, exclude}]}

Answer 2

First of all, you can try to see what fails during the booting of the VM by adding the arguments init_debug to the VM:
$ erl -init_debug
{progress,preloaded}
{progress,kernel_load_completed}
{progress,modules_loaded}
{start,heart}
{start,error_logger}
{start,application_controller}
{progress,init_kernel_started}
...
{progress,applications_loaded}
{apply,{application,start_boot,[kernel,permanent]}}
{apply,{application,start_boot,[stdlib,permanent]}}
{apply,{c,erlangrc,[]}}
{progress,started}
Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.8.4 (abort with ^G)
1>
Using this, you'll be able to see with more details the kind of interactions going on. It might be that libraries are being loaded in the wrong order, you don't support native, etc.
Second issue, the rel file containing too many applications. This is likely due to the fact that Rebar uses Reltool ot generate releases, and that different applications can be loaded depending on how granular the control is whne generating releases (see incl_cond material in the docs). There are a few examples for this in the Release is The Word chapter of Learn You Some Erlang:
{sys, [
{lib_dirs, ["/home/ferd/code/learn-you-some-erlang/release/"]},
{erts, [{mod_cond, derived}, % derived makes it pick less stuff
{app_file, strip}]},
{rel, "erlcount", "1.0.0", [kernel, stdlib, ppool, erlcount]},
{boot_rel, "erlcount"},
{relocatable, true},
{profile, embedded}, % reduces the files included from each app
{app_file, strip}, % reduces the size of app files if possible
{incl_cond, exclude}, % by default, don't include apps. 'derived' is another option
{app, stdlib, [{mod_cond, derived}, {incl_cond, include}]}, % include at the app
{app, kernel, [{incl_cond, include}]}, % level overrides the
{app, ppool, [{vsn, "1.0.0"}, {incl_cond, include}]}, % exclude put earlier
{app, erlcount, [{vsn, "1.0.0"}, {incl_cond, include}]}
]}.
And this should generate smaller releases.

Answer 3

I don't know the good answer, but I do know that I couldn't start a release running on several CentOS versions with a couple different kernels, so this isn't exactly unusual. Upgrading to 5.6 made it finally work. You can see which OSes actually get tested every day here:
http://www.erlang.org/doc/installation_guide/INSTALL.html#id62915
Also, you could compile without HIPE, I guess.

Answer 4

Lately I found this post:
http://mokele.co.uk/2011/07/01/rebar-release-upgrade-caveats.html
It uncovers a list of errors in rebar, one of them being the reason why my release couldn't launch. There are also fixes published. I hope they will be merged into main rebar repository ASAP.