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