[erlang-questions] escript's beam in in distributed environment
Håkan Mattsson
hm@REDACTED
Tue Feb 7 12:19:11 CET 2012
Use the module attribute in the escript source (e.g. -module(funky))
to control the module name.
/Håkan
On Tue, Feb 7, 2012 at 11:45, karol skocik <karol.skocik@REDACTED> wrote:
> Hi,
> I want to have an escript, which starts some slave nodes making
> requests to some target host - basically a simple load generator.
> On a slave nodes, running functions from escript directly fails, since
> slaves can't find those escript functions, which is understandable.
> For that purpose, the escript contains this function:
>
> make_beam() ->
> Name = escript:script_name(),
> AbsName = filename:absname(Name),
> {ok, Sections} = escript:extract(AbsName, [compile_source]),
> {source, BeamCode} = lists:keyfind(source, 1, Sections),
> BeamFile = filename:join("/tmp", atom_to_list(?MODULE) ++ ".beam"),
> file:write_file(BeamFile, BeamCode),
> BeamFile.
>
> The plan was:
> 1.) save the escript as a beam to the "/tmp" directory (with a funky
> name from ?MODULE - like 'gcf-tester__escript__1328__608633__210866')
> 2.) add "/tmp" to the code path on master, before starting slaves
> 3.) let the slaves load module (named ?MODULE in escript) using code
> load mechanism thru master
>
> Now the problem:
>
> When the saved escript's beam is loaded in the Erlang shell, it seems broken:
>
> (gcfc@REDACTED)5> code:add_patha("/tmp").
> true
> (gcfc@REDACTED)6> l('gcf-tester__escript__1328__608402__188688').
> {error,badfile}
> (gcfc@REDACTED)7>
> =ERROR REPORT==== 7-Feb-2012::10:54:09 ===
> Loading of /tmp/gcf-tester__escript__1328__608402__188688.beam failed: badfile
>
> =ERROR REPORT==== 7-Feb-2012::10:54:09 ===
> beam/beam_load.c(1084): Error loading module
> 'gcf-tester__escript__1328__608402__188688':
> module name in object code is gcf-tester__escript__1328__608402__542812
>
> I am using:
> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0]
> on:
> Gentoo Linux 2.6.38-tuxonice-r2-mars #9 SMP PREEMPT x86_64 Intel(R)
> Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux
>
> Is this a bug? (Maybe fixed in R15?).
> If this is an expected behavior, how do I know the final module name
> at the time of creating the escript's beam?
> And finally, what's the easiest way to "patch" the beam's binary to
> supply the correct module name?
>
> Thank you for your advice,
> Karol Skocik
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list