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

[Serge Aleynikov]

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
>>>
>