octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MXE compile and popen2


From: Tatsuro MATSUOKA
Subject: Re: MXE compile and popen2
Date: Mon, 23 May 2016 12:46:42 +0900 (JST)

> 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;
                        ^
#********************************************



reply via email to

[Prev in Thread] Current Thread [Next in Thread]