Re: MXE compile and popen2

[John Donoghue]

On 05/22/2016 11:46 PM, Tatsuro MATSUOKA wrote:
> > From: John W. Eaton
> > To: John Donoghue  "octave-maintainers
> > Cc:
> > Date: 2016/5/22, Sun 09:34
> > Subject: Re: MXE compile and popen2
> >
> > On 05/21/2016 07:33 PM, John Donoghue wrote:
> > >   On 05/21/2016 01:08 PM, John Donoghue wrote:
> > > >   On 05/20/2016 07:29 PM, address@hidden wrote:
> > > > >   Message: 1
> > > > >   Date: Fri, 20 May 2016 16:14:05 -0400
> > > > >   From: "John W. Eaton"<address@hidden>
> > > > >   To:address@hidden
> > > > >   Cc:address@hidden
> > > > >   Subject: Re: MXE compile and popen2
> > > > >   Message-ID:<address@hidden>
> > > > >   Content-Type: text/plain; charset=windows-1252; format=flowed
> > > > >
> > > > >   On 05/20/2016 04:03 PM, JohnD wrote:
> > > > >
> > > > > >   >Using const auto octave_popen2 = &octave::sys::popen2;
> > (note the
> > > > > >   >ampersand) appears to be compiling ok. Not tested yet for
> > it runs though.
> > > > >   Hmm.  Is this only failing for popen2?  What about the other
> > symbols
> > > > >   that are defined this way?  Do you not see warnings from the
> > definition
> > > > >   of octave_chdir and octave_getcwd that are also defined in
> > lo-sysdep.h?
> > > > >   jwe
> > > >   It is only for popen - I think the error is misleading, and it is
> > > >   really an issue with not knowing pid_t from within that file.
> > > >
> > > >
> > > >   I am trying with sys/types.h and will push a change up if that works
> > >
> > >   I can get past that error by defining a typedef of the function and
> > >   using that as:
> > >
> > >   +typedef pid_t (*popen_func)(const std::string&, const
> > string_vector&,
> > >   +                         bool, int *, std::string&);
> > >     OCTAVE_DEPRECATED ("use 'octave::sys::popen2' instead")
> > >   -const auto octave_popen2 = octave::sys::popen2;
> > >   +const popen_func octave_popen2 = octave::sys::popen2;
> > >
> > >
> > >   However next error occurs with the octave::sys::popen2 being defined twice:
> > >
> > >   liboctave/system/lo-sysdep.cc
> > >   liboctave/system/oct-syscalls.cc
> > That's odd.  Well, if we can't use auto here, we might as well use
> > inline wrapper functions instead of function pointers.
> >
> > jwe
>
> What I saw today in dev. build on mxe-octave is related to this post
>
> Is there a workaround temporally pass here?
> or do I have to wait until enabling build again ?
>
> Tatsuro
>
> #********************************************:
> In file included from 
> /home/tatsuro/work/octave/mxe-octave/mxe-octave-dev-w64/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/sysdep.h:33:0,
>                   from 
> /home/tatsuro/work/octave/mxe-octave/mxe-octave-dev-w64/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/oct-procbuf.cc:38:
> /home/tatsuro/work/octave/mxe-octave/mxe-octave-dev-w64/tmp-default-octave/octave-4.1.0+/liboctave/system/lo-sysdep.h:59:41:
>  error: unable to deduce 'const auto' from 'octave::sys::popen2'
>   const auto octave_popen2 = octave::sys::popen2;
>                                           ^
> /home/tatsuro/work/octave/mxe-octave/mxe-octave-dev-w64/tmp-default-octave/octave-4.1.0+/liboctave/system/lo-sysdep.h:59:12:
>  warning: 'octave_popen2' defined but not used [-Wunused-variable]
>   const auto octave_popen2 = octave::sys::popen2;
>              ^
> /home/tatsuro/work/octave/mxe-octave/mxe-octave-dev-w64/tmp-default-octave/octave-4.1.0+/libinterp/corefcn/oct-procbuf.cc:52:24:
>  warning: 'octave_procbuf_list' defined but not used [-Wunused-variable]
>   static octave_procbuf *octave_procbuf_list = 0;
>                          ^
> #********************************************

See the patch I posted on Bug #47968