无法开始使用钢筋生成的样品erlang释放 [英] Cannot start sample erlang release generated with rebar

查看:130
本文介绍了无法开始使用钢筋生成的样品erlang释放的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

一般来说,我是一个钢筋和埃尔朗的初学者。根据本教程,我正在尝试用钢筋创建一个erlang版本: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades ,并停留在运行生成版本的位置。



我的系统是Ubuntu 11.04 64bit,erlang R14B03,从源安装。



当我调用bin / somenode控制台时,我得到以下之一错误:$ / $ $ $ $ $ $ $ $ $ $ -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 / root / etc / vm.args - console
根:/ home / ghik / Inz / somerel / rel / somenode
{init终止do_boot,{'无法加载',hipe_amd64_encode,get_files}}

崩溃转储已写入:erl_cra sh.dump
init终止于do_boot()

有趣的是,每次运行它时,列出不同的原子而不是'hipe_amd64_encode',例如:'hipe_amd64_defuse','hipe_amd64_assemble'等
我猜Erlang无法加载呃,但我不知道为什么要尝试加载它首先。该版本仅包含一个非常简单的应用程序,仅依赖于内核和stdlib。



由于某些原因,rebar生成一个具有大量不必要应用程序的.rel文件:

  %% rel生成于{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},
{编译器,4.7.4,加载},
{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,负载}]}。

为什么钢筋列出了.rel文件中的许多应用程序?如果事情很好,为什么不发布?

解决方案

首先,你可以尝试看看什么失败在引导虚拟机期间,通过向虚拟机添加参数 init_debug

  $ 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,永久]}}
{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(中止与^ G)
1>

使用此功能,您将可以看到更多详细信息。可能是图书馆正在以错误的顺序加载,您不支持本机等。






第二期,该rel文件包含太多的应用程序。这可能是因为Rebar使用Reltool生成版本,并且可以根据控件产生版本的细节来加载不同的应用程序(请参阅 incl_cond 材料文档)。在发布是Word 章节中了解一些例子一些Erlang:

  {sys,[
{lib_dirs,[/ home / ferd / code / learn-you -some-erlang / release /]},
{erts,[{mod_cond,derived},%derived make it pick less stuff
{app_file,strip}]},
{rel ,erlcount,1.0.0,[kernel,stdlib,ppool,erlcount]},
{boot_rel,erlcount},
{relocatable,true},
{profile ,嵌入},%减少每个应用程序中包含的文件
{app_file,strip},%可以减少应用程序文件的大小
{incl_cond,exclude},默认情况下为%,不包括应用程序。 'derived'是另一个选项
{app,stdlib,[{mod_cond,derived},{incl_cond,include}]},%include在应用程序
{app,kernel,[{incl_cond,include} ]},%级别覆盖
{app,ppool,[{vsn,1.0.0},{incl_cond,include}]},%exclude put更早
{app,erlcount,[{ vsn,1.0.0},{incl_cond,include}]}
]}。

这应该会生成较小的版本。


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?

解决方案

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.

这篇关于无法开始使用钢筋生成的样品erlang释放的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆