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

[Jaroslav Hajek]

2010/3/25 John W. Eaton <address@hidden>:
> On 25-Mar-2010, Jaroslav Hajek wrote:
>
> | 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.
>
> Is this guaranteed to work, or are there systems where it will fail?
>
> I think it might be best to come up with some simple test cases that
> we can use to discuss the problems with the gnulib maintainers.
>
> jwe
>

I think that C++ requires that the standard C headers can be included
directly. Remember that a valid C89 program is a valid C++98 program,
except a couple of obscure cases. A problem may occur with macros
possibly defined in the C header, but usually the C++ header
#undefines the macros (otherwise the std:: prefixed versions would be
unusable). So the order matters here, but I daresay this combination
should work well. Some macros may be undefined already by gnulib (in
order to make the gnulib:: versions work).

I'm not sure whether, say, <cstring> is required to include
<string.h>. I guess not. But GCC normally does it, so I'm surprised it
doesn't work for David.

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