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

[Jaroslav Hajek]

On Fri, Mar 26, 2010 at 10:33 AM, David Grundberg <address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> On Fri, Mar 26, 2010 at 10:01 AM, David Grundberg <address@hidden>
>> wrote:
>>
>>>
>>> John W. Eaton wrote:
>>>
>>>>
>>>> On 25-Mar-2010, Jaroslav Hajek wrote:
>>>>
>>>> | 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.
>>>>
>>>> I'm not sure that it is required, but up until now we haven't had any
>>>> problems assuming that it is, and all the GCC/libstdc++ versions that
>>>> I know about do include it, so I agree that it is surprising that
>>>> David had a problem.
>>>>
>>>> I've committed a changeset that undoes most of the recent (last two
>>>> days) changes related to gnulib.
>>>>
>>>> Until I can understand what caused the problem, I'd rather not make
>>>> these changes.
>>>>
>>>> David, will you please update and see if you can reproduce the problem
>>>> on your system?  After updating, please either do a completely fresh
>>>> build or do the following
>>>>
>>>>  remove the libgnu directory from your build tree
>>>>  run autogen.sh
>>>>  run configure
>>>>  run make
>>>>
>>>> If you still have the problems you did before, then please send the
>>>> error message you see and a copy of the preprocessed file that is
>>>> causing the trouble so I can look at it.
>>>>
>>>> Thanks,
>>>>
>>>> jwe
>>>>
>>>>
>>>
>>> I removed all files in my vpath and removed the gnulib/ and libgnu/
>>> directories in the source tree. Then I pulled, updated and ran
>>> autogen.sh. I
>>> configured in my vpath again and ran 'make'. I'm still having problems.
>>>
>>> Versions:
>>>
>>> I'm running newer versions of automake, autoconf and libtool than those
>>> part
>>> of the debian system, installed separately.
>>>
>>> $ hg tip
>>> changeset:   10467:13c1f15c67fa
>>> tag:         tip
>>> user:        Jaroslav Hajek <address@hidden>
>>> date:        Fri Mar 26 08:24:04 2010 +0100
>>> summary:     guard against recursive calls of missing_function_hook
>>>
>>> $ git log | head
>>> commit decf3017fc407865acdaa20ee4795b50a010239a
>>> Author: <snip>
>>> Date:   Fri Mar 26 09:14:34 2010 +0100
>>>
>>> The error during make is very similar (if not identical) to what I got
>>> earlier. Producing dir-ops.ii:
>>>
>>> $ cd liboctave
>>> $ g++ -DHAVE_CONFIG_H -I.
>>> -I/Home/staff/davidg/octave-patching/octaveorg/liboctave -I..
>>> -I/Home/staff/davidg/octave-patching/dependencies/CHOLMOD/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/UMFPACK/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/AMD/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/CAMD/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/COLAMD/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/CCOLAMD/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/CXSparse/Include/
>>> -I/Home/staff/davidg/octave-patching/dependencies/UFconfig/ -I../libgnu
>>> -I/Home/staff/davidg/octave-patching/octaveorg/libgnu
>>> -I/Home/staff/davidg/octave-patching/octaveorg/libcruft/misc
>>> -I/Home/staff/davidg/octave-patching/dependencies/UFconfig/ -O0 -ggdb
>>> -DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow
>>> -Wold-style-cast -Wformat -O0 -ggdb -pthread -O0 -ggdb -MT
>>> liboctave_la-dir-ops.lo -MD -MP -MF .deps/liboctave_la-dir-ops.Tpo -c
>>> /Home/staff/davidg/octave-patching/octaveorg/liboctave/dir-ops.cc  -fPIC
>>> -DPIC -o .libs/liboctave_la-dir-ops.o --save-temps
>>> /Home/staff/davidg/octave-patching/octaveorg/liboctave/dir-ops.cc: In
>>> member
>>> function ‘bool dir_entry::open(const std::string&)’:
>>> /Home/staff/davidg/octave-patching/octaveorg/liboctave/dir-ops.cc:61:
>>> error:
>>> ‘strerror’ is not a member of ‘gnulib’
>>> $
>>>
>>> David
>>>
>>>
>>
>> Wicked. Can you share the /usr/include/c++/4.3/cstring file?
>>
>>
>>
>>
>
> Sure thing.
>
> David
>
> // -*- C++ -*- forwarding header.
>
> // Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
> // Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
> // terms of the GNU General Public License as published by the
> // Free Software Foundation; either version 2, or (at your option)
> // any later version.
>
> // This library is distributed in the hope that it will be useful,
> // but WITHOUT ANY WARRANTY; without even the implied warranty of
> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> // GNU General Public License for more details.
>
> // You should have received a copy of the GNU General Public License
> // along with this library; see the file COPYING.  If not, write to
> // the Free Software Foundation, 51 Franklin Street, Fifth Floor,
> // Boston, MA 02110-1301, USA.
>
> // As a special exception, you may use this file as part of a free software
> // library without restriction.  Specifically, if other files instantiate
> // templates or use macros or inline functions from this file, or you
> compile
> // this file and link it with other files to produce an executable, this
> // file does not by itself cause the resulting executable to be covered by
> // the GNU General Public License.  This exception does not however
> // invalidate any other reasons why the executable file might be covered by
> // the GNU General Public License.
>
> /** @file cstring
>  *  This is a Standard C++ Library file.  You should @c #include this file
>  *  in your programs, rather than any of the "*.h" implementation files.
>  *
>  *  This is the C++ version of the Standard C Library header @c string.h,
>  *  and its contents are (mostly) the same as that header, but are all
>  *  contained in the namespace @c std (except for names which are defined
>  *  as macros in C).
>  */
>
> //
> // ISO C++ 14882: 20.4.6  C library
> //
>
> #pragma GCC system_header
>
> #include <bits/c++config.h>
> #include <cstddef>
> #include_next <string.h>
>
> #ifndef _GLIBCXX_CSTRING
> #define _GLIBCXX_CSTRING 1
>
> // Get rid of those macros defined in <string.h> in lieu of real functions.
> #undef memchr
> #undef memcmp
> #undef memcpy
> #undef memmove
> #undef memset
> #undef strcat
> #undef strchr
> #undef strcmp
> #undef strcoll
> #undef strcpy
> #undef strcspn
> #undef strerror
> #undef strlen
> #undef strncat
> #undef strncmp
> #undef strncpy
> #undef strpbrk
> #undef strrchr
> #undef strspn
> #undef strstr
> #undef strtok
> #undef strxfrm
>
> _GLIBCXX_BEGIN_NAMESPACE(std)
>
>  using ::memchr;
>  using ::memcmp;
>  using ::memcpy;
>  using ::memmove;
>  using ::memset;
>  using ::strcat;
>  using ::strcmp;
>  using ::strcoll;
>  using ::strcpy;
>  using ::strcspn;
>  using ::strerror;
>  using ::strlen;
>  using ::strncat;
>  using ::strncmp;
>  using ::strncpy;
>  using ::strspn;
>  using ::strtok;
>  using ::strxfrm;
>
>  inline void*
>  memchr(void* __p, int __c, size_t __n)
>  { return memchr(const_cast<const void*>(__p), __c, __n); }
>
>  using ::strchr;
>
>  inline char*
>  strchr(char* __s1, int __n)
>  { return __builtin_strchr(const_cast<const char*>(__s1), __n); }
>
>  using ::strpbrk;
>
>  inline char*
>  strpbrk(char* __s1, const char* __s2)
>  { return __builtin_strpbrk(const_cast<const char*>(__s1), __s2); }
>
>  using ::strrchr;
>
>  inline char*
>  strrchr(char* __s1, int __n)
>  { return __builtin_strrchr(const_cast<const char*>(__s1), __n); }
>
>  using ::strstr;
>
>  inline char*
>  strstr(char* __s1, const char* __s2)
>  { return __builtin_strstr(const_cast<const char*>(__s1), __s2); }
>
> _GLIBCXX_END_NAMESPACE
>
> #endif
>
>

OK, so now it's clear. It's the #include_next on line 49 that makes
the difference. My g++ 4.4 has a plain #include there.
I don't know why your g++ uses include_next in this case, but since
it's still a relatively new version, we simply can't rely on that
cstring will properly include <string.h>. I think that my proposal to
include both the C header and the C++ header, in this order, was the
safest thing we can achieve.

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