| Author |
Message |
< Erlang ~ Build and run in different locations |
| Tronman |
 Posted: Tue Mar 23, 2010 8:41 pm |
 |
|
|
Joined: 23 Mar 2010
Posts: 6
|
Hi there,
For reasons beyond my control, I have to run erlang on a system separate from the one I built it on.
When building, I used prefix to specify a directory to place the resulting binaries. On my build system, I can run erlang just fine.
But when I tried to copy the compiled files to the run system, I get the error "/erlexec: not found", which makes sense since the preceding path its looking for was where it was built, not where I need to run it. Is there a flag of some sort I can pass to tell it the "top level" location of where it should look for it's files?
I also noticed the exact directory I specified for prefix was blank, instead it seemed to place everything one level up (where I had the source), since now I'm not sure precisely what is required to run the system on the other machine. The "bin" directory obviously, and possibly the "lib" directory? Is there anything else?
Thanks! |
|
|
| Back to top |
 
|
| zajda |
| Posted: Wed Mar 24, 2010 8:17 am |
|
|
|
User
Joined: 22 Aug 2009
Posts: 83
|
What you need is a release and a target system.
Once you have it, you can build a tarball, send it to any machine, unpack and it all works (it covers issues with erlang runtime system and other erlang dependencies).
Here is documentation: http://www.erlang.org/doc/design_principles/release_structure.html#id2273097
Be careful with Crypto and SSL applications, while c drivers inside, need to be compiled for the target architecture.
Michał Zajda
------------------
Erlang Solutions Ltd |
|
|
| Back to top |
|
| Tronman |
| Posted: Wed Mar 24, 2010 5:55 pm |
|
|
|
Joined: 23 Mar 2010
Posts: 6
|
zajda wrote: What you need is a release and a target system.
Once you have it, you can build a tarball, send it to any machine, unpack and it all works (it covers issues with erlang runtime system and other erlang dependencies).
Here is documentation: http://www.erlang.org/doc/design_principles/release_structure.html#id2273097
Be careful with Crypto and SSL applications, while c drivers inside, need to be compiled for the target architecture.
Michał Zajda
------------------
Erlang Solutions Ltd
Hey, thanks for the response. Yes, I do definitely have native libraries for OpenSSL, but I'm not quite sure what the link you sent means. It seems to indicate making "erlang" releases which include applications written in erlang? I suppose ultimately that's what I want to do, but at first I was trying trying to get a working system running. I don't see how to do this with that documentation.
In the long run, I have a heavily modified version of ejabberd that I'm trying to run on a solaris 10 box. But the solaris 10 box doesn't have erlang installed naively, nor any build tools (no gcc, make, etc). Now, I did manage to build erlang on another Solaris 10 box, and it runs just fine, but all the paths are wrong when I try to run it on the run box. So how to I use the "release" architecture to make an erlang system in a tar ball that I can put on the other machine and have it run without broken paths? Any advice would be helpful! Thanks. |
|
|
| Back to top |
|
| zajda |
| Posted: Thu Mar 25, 2010 2:57 pm |
|
|
|
User
Joined: 22 Aug 2009
Posts: 83
|
You have to take care of gcc and make by yourself on each box. I have no answer for that.
I assumed that wrong paths problem considers erlang components like: mnesia or even run time system.
It occurs when our application uses those OTP components and on some another box our app cannot find them (i.e. because erlang/otp is not installed there)
Target system addresses this problem. It basically makes local copy of ERTS and components you want to use. (they run on VM so it means system independent, only consideration is to have properly compiled VM).
When you have it in such a system there is no problems with paths. Only switch ERTS/SSL/Crypto for proper one (compiled for target arch) and every thing works out of the box. This is only one of many advantages of a release, for free you get: more robustness, code upgrade and simpler distribution.
Link which I sent before, describes how to organize components, so default scripts can load and recognize them.
Maybe this is not the best and clear documentation  , so check out some erlang books by Joe Armstrong or Cesarini&Thomson.
Michał Zajda
------------------
Erlang Solutions Ltd |
|
|
| Back to top |
|
| Tronman |
| Posted: Thu Mar 25, 2010 5:42 pm |
|
|
|
Joined: 23 Mar 2010
Posts: 6
|
zajda wrote: You have to take care of gcc and make by yourself on each box. I have no answer for that.
I assumed that wrong paths problem considers erlang components like: mnesia or even run time system.
It occurs when our application uses those OTP components and on some another box our app cannot find them (i.e. because erlang/otp is not installed there)
Target system addresses this problem. It basically makes local copy of ERTS and components you want to use. (they run on VM so it means system independent, only consideration is to have properly compiled VM).
When you have it in such a system there is no problems with paths. Only switch ERTS/SSL/Crypto for proper one (compiled for target arch) and every thing works out of the box. This is only one of many advantages of a release, for free you get: more robustness, code upgrade and simpler distribution.
Link which I sent before, describes how to organize components, so default scripts can load and recognize them.
Maybe this is not the best and clear documentation , so check out some erlang books by Joe Armstrong or Cesarini&Thomson.
Hey, thanks again for your help. I think I understand what you mean, but not sure that addresses my problem. I have no way to put gcc or make on the runtime box, but they shouldn't be necessary anyway in order to run erlang (unless you're saying its an absolute requirement erlang run's on the box where it's built, but that doesn't make sense).
I was however able to replicate the build path on the run time system. So I copied my built erlang system over to the run time system, and ran erl. Good news: I get to Eshell V5.7.2 shell. But something odd is happening. On my build machine, if I try to run erl, I'll see this:
Erlang R13B01 (erts-5.7.2) [source] [smp:128:128] [rq:128] [async-threads:0] [kernel-poll:false]
Eshell V5.7.2 (abort with ^G)
But, after coping everything over, if I try to run erl on the runtime machine, all I see is:
Eshell V5.7.2 (abort with ^G)
What could the missing "Erlang R13B01" mean about how the system setup and any problems I might run into because of it? Could there be a shared object or some component missing? Must there be something special in my path?
Now, the application (ejabberd in this case) is configured to use the correct erlang on the run-time box, which is great, though I can't connect any XMPP clients and get a "{badarg,[{erlang,port_control," message when I try. I can make accounts, and even hit the web interface though.
It's definably being run on the same system version it was built: however I feel the issue may be related to the missing "Erlang R13B01" when I try to run erl.
Any further advice on this is appreciated! Thanks. |
|
|
| Back to top |
|
| zajda |
| Posted: Fri Mar 26, 2010 6:27 am |
|
|
|
User
Joined: 22 Aug 2009
Posts: 83
|
yes, of course, gcc is not required to run erlang. It is possible to cross-compile etc.. but now I see that you dont have to do it, while two boxes run on the same system.
..not realy sure what means this missing header in erlang shell, is it operational? e.g. what returns?
about the ejabberd, please copy-paste the whole crash, with app and reason.
btw. I love the number of your rq/cores |
|
|
| Back to top |
|
| Tronman |
| Posted: Fri Mar 26, 2010 3:42 pm |
|
|
|
Joined: 23 Mar 2010
Posts: 6
|
zajda wrote: yes, of course, gcc is not required to run erlang. It is possible to cross-compile etc.. but now I see that you dont have to do it, while two boxes run on the same system.
..not realy sure what means this missing header in erlang shell, is it operational? e.g. what returns?
about the ejabberd, please copy-paste the whole crash, with app and reason.
btw. I love the number of your rq/cores
Hey, yep it seems to be operational. i(). returns a whole host of stuff, "Pid, Initial, Call, Heap, Reds Msgs, Registered, Current, Function, Stack". Plus I can so simple ops like io:format("Hello!\n", []) and promptly get
Hello!
ok
as expected.
As for the specified ejabberd problem, it seems to be running now, basically some of the shared objects in the /lib directory (like expat_erl.so, tls_drv.so) were missing dependencies, so I had to find them all and put them in $LD_LIBRARY_PATH, and now it works! Which is great, but it is running slower then I would expect. Even invoking erl seems to take a few seconds to start.
Is there a way to check if kernel poll is working properly without the header? I know ordinarily, you just run erl +K true and look for [kernel-poll:true], but since I don't get anything before the Eshell, I can't tell. Any ideas on how to check otherwise? Is there a shared object or something it needs for kernel poll that might be missing a dependency? Or any other reason it might be so laggy? Thanks! |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
