[erlang-questions] can a program launched with open_port({spawn, Cmd}, Options) remain running after the port closes?

[Tim Watson]

Well I do, but clearly not the same version as you?

t4@REDACTED:erlexec $ which libtool
/usr/bin/libtool
t4@REDACTED:erlexec $ ls -la /usr/bin/ | grep libtool
-r-xr-xr-x     1 root   wheel    149216 22 May 15:30 libtool
lrwxr-xr-x     1 root   wheel         7 22 May 15:30 ranlib -> libtool
t4@REDACTED:erlexec $ libtool --version
libtool: unknown option character `-' in: --version
Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
t4@REDACTED:erlexec $ 

Honestly the osx build tool chain drives me nuts sometimes. :/

On 28 Sep 2012, at 17:24, Serge Aleynikov wrote:

> Is it possible that you don't have libtool installed (missing
> AC_PROG_LIBTOOL)?
> 
> I have the following on linux and everything builds fine:
> $ autoconf -V
> autoconf (GNU Autoconf) 2.68
> $ libtool --version
> libtool (GNU libtool) 2.4
> $ ./build
> $ make
> $ make install
> $ tree install
> install
> └── exec-1.0
>    ├── ebin
>    │   ├── exec.app
>    │   ├── exec_app.beam
>    │   └── exec.beam
>    ├── include
>    │   └── exec.hrl
>    ├── priv
>    │   └── x86_64-unknown-linux-gnu
>    │       └── bin
>    │           └── exec-port
>    └── src
>        ├── exec_app.erl
>        └── exec.erl
> 
> 
> On 9/28/2012 7:45 AM, Tim Watson wrote:> The project doesn't appear to
> build cleanly on mac os lion:
>> 
>> t4@REDACTED:erlexec $ ./configure
>> configure: error: cannot find install-sh, install.sh, or shtool in
> config "."/config
>> t4@REDACTED:erlexec $ ./build
>> Install dir: /usr/local/src/erlang/erlexec/install
>> aclocal
>> autoconf -i
>> configure.ac:19: error: possibly undefined macro: AC_PROG_LIBTOOL
>>     If this token and others are legitimate, please use m4_pattern_allow.
>>     See the Autoconf documentation.
>> make: *** [configure] Error 1
>> t4@REDACTED:erlexec $
>> t4@REDACTED:erlexec $ autoconf -V
>> autoconf (GNU Autoconf) 2.69
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+/Autoconf: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>,
> <http://gnu.org/licenses/exceptions.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> Written by David J. MacKenzie and Akim Demaille.
>> t4@REDACTED:erlexec $
>> 
>> 
>> Is there a specific version of autotools required to build and compile
> erlexec?
>> 
>> On 27 Sep 2012, at 20:11, Tim Watson wrote:
>> 
>>> On 27 Sep 2012, at 19:18, freza@REDACTED wrote:
>>>> Haven't been following this thread closely, but it seems erlexec wasn't
>>>> mentioned yet:
>>>> 
>>>> 	http://code.google.com/p/erlexec/
>>> 
>>> Doesn't appear very well maintained. I might pick it apart and
> rewrite it when native processes get released - it is a cool idea.
> Anyway, for the time being it's not a great help as I'm writing a
> framework to help set up and tear down clusters for distributed testing
> (based largely on common test) so I want to minimise the number of
> dependencies as much as possible. Besides, I'm more interested in
> working on the remote/ssh runner+monitor next, rather than spending
> another age fiddling around with the script runner.
>>> 
>>> But yes, erlexec does look interesting and has been on my radar since
> it popped up on this list a few months back, discussing the desire to do
> proper signal handling (such as sending SIGTERM, SIGHUP, etc to the
> external program) without resorting to os:cmd("kill -" ++ Code ++ " " ++
> OsPid). Again, this is something that linked-in drivers *can* deal with
> to a limited extent, and therefore I suspect that native processes will
> make for a very nice foundation on which to build an alternative to
> open_port/2.
>>> 
>>> Also, IIRC there was a cool command line testing framework open
> sourced in the last year which was announced on this list. I can't
> remember what it was called, but it has a port driver that handles the
> the external comms and so on - looked very nice, although that's not
> what I'm trying to do/be as my focus is on getting things in a
> consistent state and monitoring to make sure they stay that way through
> the test run, then tearing down nicely before the next phase kicks off.
>>> 
>>> Cheers,
>>> Tim
>> 
>> 
>> 
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120928/91e1ae76/attachment.bin>