When I try to bootstrap CMake (regardless of parameters for as far as I can see) it fails with the following error:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
CURSES_CURSES_H_PATH
used as include directory in directory /usr/src/cmake-2.8.6/Source/CursesDialog/form
used as include directory in directory /usr/src/cmake-2.8.6/Source
Although it can find libcurses...
-- Looking for wsyncup in /usr/lib/libcurses.so
-- Looking for wsyncup in /usr/lib/libcurses.so - found
The problem seems to lie in the fact that my curses.h header file is in /usr/include/ncursesw instead of in /usr/include. It would seem that CMake needs curses to build and cannot use ncurses... Strangely, I've compiled ncurses conform Linux From Scratch and which places the headers in that subfolder (ncursesw). Compiling non-wide versions didn't work either, as the headers are placed in /usr/include/ncurses. CMake is part of Beyond Linux From Scratch, but I don't see any workarounds there, so I'm puzzled why BLFS doesn't encounter the same problems...
I've come up with a workaround that works for my situation, but I don't know if this is a good solution or will cause problems in the future...
sed -i "s#FIND_FILE(CURSES_HAVE_CURSES_H curses.h )#FIND_FILE(CURSES_HAVE_CURSES_H curses.h HINTS /usr/include/ncursesw )#" Modules/FindCurses.cmake
sed -i "s#FIND_PATH(CURSES_CURSES_H_PATH curses.h )#FIND_PATH(CURSES_CURSES_H_PATH curses.h HINTS /usr/include/ncursesw )#" Modules/FindCurses.cmake
I've hinted the FindCurses script to look for curses.h in the /usr/include/ncursesw folder.
This is a blog on which I post my experiences with messing with computer systems and software, such as Linux From Scratch and my Windows Domain. I hope to help people by posting the errors that I encounter and the solutions that I, hopefully, find.
Sunday, October 16, 2011
Sunday, October 2, 2011
Test "samba3.blackbox.smbclient_s3.crypt" in samba 3.6.0 fails
I got the following two errors from one of the tests in the Samba 3.6.0 test suite:
UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).writing into a read-only directory fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e
UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).Reading a owner-only file fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e
The solution to these errors is to run the test suite as a non-root user (which is always a good idea). Unfortunately, since I use automated scripts to compile, test and configure packages (wrote them myself), it is difficult to switch users half way (you need root for installing). My solution was to su to a non-root user just for these tests and let him own the entire source tree, so that there are no access problems.
UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).writing into a read-only directory fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e
UNEXPECTED(failure): samba3.blackbox.smbclient_s3.crypt (s3dc).Reading a owner-only file fails
REASON: _StringException: _StringException: CLI_FORCE_INTERACTIVE=yes /usr/src/samba-3.6.0/source3/bin/smbclient -U% //LOCALS3DC2/ro-tmp -I 127.0.0.2 --configfile=/usr/src/samba-3.6.0/source3/st/client/client.conf -e
The solution to these errors is to run the test suite as a non-root user (which is always a good idea). Unfortunately, since I use automated scripts to compile, test and configure packages (wrote them myself), it is difficult to switch users half way (you need root for installing). My solution was to su to a non-root user just for these tests and let him own the entire source tree, so that there are no access problems.
Subscribe to:
Posts (Atom)