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

[David Grundberg]

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.

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