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

[Tim Watson]

I'm a heavy rebar user and have compiled ports with it before, so give me a shout if you need any assistance. I can also do testing on several unix platforms. 

On 28 Sep 2012, at 22:41, Serge Aleynikov <serge@REDACTED> wrote:

> Unfortunately I don't have OSx to test this.  I can't reproduce your
> problem on Linux.  Perhaps you could check the libtool version this way:
> 
> $ grep "^macro_version" /usr/bin/libtool
> macro_version=2.4
> 
> and if yours is different, try to upgrade it.
> 
> In order to simplify the build process I'll try to convert erlexec to
> use rebar some time next week, which will eliminate autotools-based
> toolchain.  Need to figure out with rebar how to test and optionally
> enable conditional defines based on presence of special C headers such
> as "sys/capability.h" when compiling a port program.
> 
> On 9/28/2012 5:16 PM, Tim Watson wrote:> 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
>>>> 
>>