octave-maintainers
[Top][All Lists]
Advanced

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

Re: build fails: ‘strerror’ is not a member of ‘gnulib’


From: Jaroslav Hajek
Subject: Re: build fails: ‘strerror’ is not a member of ‘gnulib’
Date: Thu, 25 Mar 2010 11:33:30 +0100

On Thu, Mar 25, 2010 at 11:29 AM, David Grundberg <address@hidden> wrote:
> John W. Eaton wrote:
>>
>> On 24-Mar-2010, David Grundberg wrote:
>>
>> | I'm having trouble building the tip. I used to have the 'cannot open < |
>> liboctave/mx-op-inc.mk' problem but that is fixed now, that's great, but |
>> I'm still stuck. I removed my checkout and started anew, but it still |
>> won't build. This is what I'm getting:
>>
>> I assume you checked in the following change to fix this problem?
>>
>> Why did you use (for example)
>>
>>  #include "stdlib.h"
>>
>> instead of
>>
>>  #include <stdlib.h>
>>
>> ?  Is this needed because some system C++ <cXXX> headers don't include
>> the corresponding C <XXX.h> header files?  If so, then maybe we should
>> be rethinking the way we use the C system headers throughout Octave.
>>
>
> I could have used <stdlib.h> instead of "stdlib.h", but I felt like using ""
> because the file is in the source tree.
>
> As for using <cstring>, this doesn't include gnulib's string.h for me.
>

What if you do
#include <string.h>
#include <ctring>

? Does that help? If so, I think this would be the best pattern.


> Consider this example:
>
> #include "config.h"
> #include <cstring>
>
> #ifdef WORK
> // Include gnulib's string.h
> #include <string.h>
> #endif
>
> int main ()
> {
>   gnulib::strerror (0);
>   return 0;
> }
>
> Here it will not compile if WORK is undefined. (So this works: g++
> gnulibtest.cc -I. -Ilibgnu -DWORK)
>
>> Also, even though we may expect these headers to be coming from gnulib
>> now,
>> if we had a system that did not need gnulib to provide proper
>> POSIX support, I think we would want the <...> style of include
>> statements.  Won't it work properly to include them with <...> now
>> given the -I flags we provide to the preprocessor?
>>
>
> As demonstrated, #include <string.h> works too. I don't have strong opinions
> whether to use <string.h> or "string.h".
>
> David
>
>



-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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