[erlang-questions] escript's beam in in distributed environment

[karol skocik]

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