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

[Jaroslav Hajek]

On Thu, Mar 25, 2010 at 9:53 AM, Jaroslav Hajek <address@hidden> wrote:
> 2010/3/24 David Grundberg <address@hidden>:
>> John W. Eaton wrote:
>>> On 24-Mar-2010, David Grundberg wrote:
>>>
>>> | Hi everybody,
>>> |
>>> | 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:
>>> |
>>> | address@hidden:/scratch/octaveorgvpath$ make
>>> | making run-octave from
>>> | /Home/staff/davidg/octave-patching/octaveorg/run-octave.in
>>> | run-octave is unchanged
>>> | chmod a+rx "run-octave"
>>> | make  all-recursive
>>> | make[1]: Entering directory `/scratch/octaveorgvpath'
>>> |
>>> | <snip>
>>> |
>>> |
>>> | make[3]: Entering directory `/scratch/octaveorgvpath/liboctave'
>>> | /Home/staff/davidg/octave-patching/octaveorg/liboctave/config-ops.sh
>>> | /Home/staff/davidg/octave-patching/octaveorg vx inc
>>> | /Home/staff/davidg/octave-patching/octaveorg/liboctave/vx-op-inc.mk is
>>> | unchanged
>>> | /bin/sh ../libtool  --tag=CXX   --mode=compile 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 -o
>>> | liboctave_la-dir-ops.lo `test -f 'dir-ops.cc' || echo
>>> | '/Home/staff/davidg/octave-patching/octaveorg/liboctave/'`dir-ops.cc
>>> | libtool: compile:  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
>>> | /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’
>>> | make[3]: *** [liboctave_la-dir-ops.lo] Error 1
>>> | make[3]: Leaving directory `/scratch/octaveorgvpath/liboctave'
>>> | make[2]: *** [all] Error 2
>>> | make[2]: Leaving directory `/scratch/octaveorgvpath/liboctave'
>>> | make[1]: *** [all-recursive] Error 1
>>> | make[1]: Leaving directory `/scratch/octaveorgvpath'
>>> | make: *** [all] Error 2
>>> | address@hidden:/scratch/octaveorgvpath$
>>> |
>>> | Any clues?
>>>
>>> If you want to debug this, then add -save-temps to the compiler
>>> command for dir-ops.cc and look at the generated .ii file to see where
>>> the declaration is coming from.  There should be a declaration of a
>>> function pointer named strerror in the gnulib namespace that looks
>>> like this:
>>>
>>>   namespace gnulib { static char * (*strerror) (int) = ::strerror; }
>>>
>>> If you don't have that, then why not?  Is your copy of gnulib up to date?
>>>
>>> jwe
>>>
>>
>> Thanks for the hint, didn't know about --save-temps. Always used -E
>> which was painful. Yes gnulib is supposed to be brand new (7bacd338464,
>> Mon Mar 22). I don't get the gnulib::strerror at all, just extern
>> declarations. The only way I know how to make this work is to replace
>> <cstring> with "string.h", etc.
>>
>> Checked in:
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/12d25a1d84bf
>>
>> David
>>
>
> Ugh, please don't do it, at least for cmath. cmath is needed to be
> able to use the std:: prefixed funcs. Some are standard, others can be
> discovered using the OCTAVE_CMATH_FUNC macro. The std::isnan etc.
> functions provide optimizations that you don't want to miss (or I
> don't at least).
> I don't know whether gnulib can provide equally efficient isnan; if
> so, perhaps we can resign on using the std:: variants.
>

Thinking about this a bit more, it won't work, because isnan et al.
are macros in C (for good reasons) and so gnulib also only provides
macros. However, the macros won't work (for good reasons) if <cmath>
is included, because it undefines them. And you can't generally avoid
including cmath (it's usually included by <complex>, for instance).

Once again we're hitting the problem that gnulib is meant for C, not
C++. We can't avoid the <cXXX> headers in general. If gnulib really
can't be forced to play nicely with C++, we should probably not use
it.



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