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

[Jaroslav Hajek]

On Thu, Mar 25, 2010 at 11:44 AM, David Grundberg <address@hidden> wrote:
> Jaroslav Hajek 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 see that you've included both cmath and gnulib's math.h. I think that's
> the way to go.
>
> Reverted modf usage now that cmath is back
> http://hg.savannah.gnu.org/hgweb/octave/rev/9684b3c3b417
>
>> I don't know whether gnulib can provide equally efficient isnan; if
>> so, perhaps we can resign on using the std:: variants.
>>
>>
>
> I don't think that is necessary.
>
> Sorry for the trouble.
>
> David
>

That's good. Back in the times when xisnan was done through lo-ieee.c,
it's performance sucked compared to what compilers can offer. With
modern g++, std::isnan, std::isinf and std::isfinite are all
efficiently inlined to just a few machine instructions.
I think math is surely one place where performance matters (and Octave
is mostly about math), so I'm against crippling speed for dubious
portability concerns.
Letting functions like round and trunc be handled with gnulib is
relatively OK, because these are typically not inlined.


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