Filodej's Linux groping

WMU-6500FS - Print server installation

2009-11-19T09:35:00.033+01:00

Introduction

Since I have one LPT printer and several computers at home I considered buing a print server for a long time. What reliably discouraged me however was the price - for example HP print server price starts at around 140$.
Unfortunately I haven't bought a router with USB ports like Asus WL-500W, but rather Linksys WRT54GL and so the printer sharing as described at DD-WRT wiki was not applicable in my case.
Then I noticed that there is a p910nd print daemon package available at the JoKer's site.
There was not much information about the installation on the Web and so I was pretty unsure but I decided to give it a try.

Note: Before you follow the steps I describe here, please, make sure your printer is compliant with the JetDirect technology.

Hardware installation

My HP LaserJet 1100 printer is not USB but LPT, so there is some USB to LPT reduction necessary.
I also realized that there is not a standard printer cable but rather a Mini Centronics cable used for the printer connection.

So it seemed that besides something like the USB to Parallel port adapter (14$) also another reduction like Centronics to Mini Centronics adapter (11$) was necessary (there is also a combo for 24$ so you can spare a buck ;).

Since I already had a standard printer cable the best choice for me was the ST Lab U-370 Dongle. For only 11$ does the job very well.
So that's it regarding to hardware installation.

Software installation

We download and install the p910nd print daemon (I use 0.92 version, I had no luck with the latest 0.93 version, I got /var/lock/subsys/p9100d file not found error).
Edit: now the problem with 0.93 is solved, see the discussion below

box# cd /mnt/C
box# wget http://mgb111.pradnik.net/addons/servers-print/p910nd-0.92-081017.tar
box# tar xvf p910nd-0.92-081017.tar
./sys/
./sys/etc/
./sys/man/
./sys/man/man8/
./sys/man/man8/p910nd.8
./sys/sbin/
./sys/sbin/p910nd

Now we are ready to plug the printer to USB port (suppose you use the USB1 port specifically) and run the daemon:

box# /mnt/C/sys/sbin/p910nd -b -f /dev/usblp0

We can see that the process is now up and running. The fact that it is named p9100d (instead of original p910nd) means that it is listening at port 9100.

box# ps | grep p910
  271 root        284 S   /mnt/C/sys/sbin/p9100d -b -f /dev/usblp0
 1863 root        216 S   grep p910

We can make sure it is actually listening at the port; when we run the network statistics to list all the ports all the processes are are listening for, newly we can see the jetdirect port.

box# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
...
tcp        0      0 *:jetdirect             *:*                     LISTEN      
...

We can also look at the system log (with help of the dmesg command). There we can find something similar to the following:

box# dmesg
...
hub.c: new USB device 00:0a.0-2, assigned address 2
printer.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
...

When we retrieve the description string of the USB device, we get that there is a IEEE-1284 (parallel communication) controller made by the Prolific Technology Inc..

box# cat /proc/printer/usblp0
Prolific Technology Inc. IEEE-1284 Controller
0x18

Note that in case you have a USB printer you should probably expect somewhat more meaningful string like

Hewlett-Packard HP LaserJet 1005 series

Now we are ready to try some printing:

box# echo "printer test" > /dev/usblp0 
...

Initially I got the following error message:

bash: /dev/usblp0: Device or resource busy

... then I realized that there is a mini-lpd process running holding the device. mini-lpd is a small, non-queueing LPD implementation. I do not know why there is mini-lpd active on the box, I have not tried to make it work, I just killed it and used p910nd daemon instead:

box# killall mini-lpd

After that everything started to work.
To make the changes permanent, I have added add the following lines:

### printserv
killall mini-lpd
/mnt/C/sys/sbin/p910nd -b -f /dev/usblp0 &

to the /mnt/C/sys/etc/rc-local file.

Ok, that's it on the server side, let's look at the clients...

Client installation

Now it is time to install the print clients:
Windows XP
I presume you already have the printer installed locally, and so the only thing you need is to create a new port and set it up as a Standard TCP/IP Port: Now you select the box IP or network name: As a device type you choose the Hewlett Pacjkard Jet Direct: Here is a result page(SNMP not supported, RAW protocol, port 9100): Here we see the newly created port: And finally we are ready to print test page:
Ubuntu 9.10
In menu System/Administration/Printing we choose to create a new printer and in device selection choose Network Printer and AppSocket/HP JetDirect.In Host and Port fields we fill the box IP or network name and as port we use 9100: The next step is the Printer model and driver selection: Now we can specify the printer name and description: And finally we are ready to print test page:

WMU-6500FS - Deluge 1.1.5

2009-04-13T22:35:00.011+02:00

I just finished a build of the deluge 1.1.5. It is bit outdated (the 1.1.6 version is out now) but I had to solve some problems along the way which taken more time than expected. Once it was finished I did not find a morale to step one bugfix version further.

Build result

[binary] [file list]

Prerequisites

The same as for the previous version plus:
[patched python socket module] [tar 1.22] [bzip2 lib]

Uninstall

If you have the deluge-1.1.0 installed, you have to clean it up first (while preserve all the dependencies).
Stop the deluge daemon if it is running. You can do it via console:

box# deluge --ui=null
>>> halt
>>> quit
Thanks!

or forcibly:

box# killall deluged

Now uninstall the previous version:

dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.1.0
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.1.0 locally at /mnt/C (y/n)?y
...

If you are not using the filopack packaging system, you can remove the previous version as follows:

box# cd /mnt/C/
box# wget http://filodej.ic.cz/filopack/.filopack/deluge-1.1.0.lst
box# xargs rm -f < deluge-1.1.0.lst

Update the system

Before we start installing the new version, we have to update the tar archiver. The one which is part of the busybox has an ugly bug corrupting file names in long paths.

box# ./filopack.sh --download bzip2-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package bzip2-1.0.5 from http://filodej.ic.cz ...
connected!

Length: 191 [text/plain]
connected!

Length: 40,244 [application/x-tar]

box# ./filopack.sh --install bzip2-1.0.5
...
box# ./filopack.sh --download tar-1.22
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package tar-1.22 from http://filodej.ic.cz ...
connected!

Length: 1,523 [text/plain]
connected!

Length: 625,455 [application/x-tar]

box# ./filopack.sh --install tar-1.22
...

For details about the bug see this section.
Also it may be necessary to download a patched version of python socket library, you can test your system as follows:

box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
Segmentation fault

... if you encounter the segfault, it is better to download and install the patched python socket library:

box# wget http://filodej.ic.cz/filopack/_socket.so
connected!

Length: 116,767 [text/plain]

box# mv sys/lib/python2.5/lib-dynload/_socket.so{,.backup}
box# mv _socket.so sys/lib/python2.5/lib-dynload/

Now the problem should be fixed:

box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
['80.68.88.204']

For details about this issue see this section.

Install

After we updated the system we are ready to install the new version:

box# ./filopack.sh --download deluge-1.1.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package deluge-1.1.5 from http://filodej.ic.cz ...
connected!

Length: 89,430 [text/plain]
connected!

Length: 16,084,717 [application/x-tar]

box# ./filopack.sh --install deluge-1.1.5
Sure to unpack deluge-1.1.5 locally at /mnt/C (y/n)? y
...

Run daemon

Now we are ready to try the daemon, still it is necessary to use the LD_PRELOAD prefix or deluged.sh script:

box# deluged.sh

That's all. Following text just describes details related to the issues I solved. Nothing for ordinary users ;-)

Busybox tar bug

When I run the deluge client (console version) some commands was not properly interpreted:

box# deluge
>>> info
 * unknown command: info
>>> help
 * unknown command: help

I found out that any command is implemented in a separate python file:

box# cd sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg
box# ls deluge/ui/console/commands/
add.py          config.pyc   debug.pyc       help.pyc        __init__.pyc    quit.pyc    rm.pyc
add.pyc         connect.py   halt.py0000755  info.py0000755  pause.py        resume.py
add.pyc0000644  connect.pyc  halt.pyc        info.pyc        pause.pyc       resume.pyc
config.py       debug.py     help.py0000755  __init__.py     quit.py0000755  rm.py

... it seems there are some ill-named files in the command directory, and so the console does not know the commands at all.
Let's find all such corrupted files:

box# find . -name *0000*
./deluge/core/preferencesmanager.pyc0000644
./deluge/ui/console/commands/quit.py0000755
./deluge/ui/console/commands/help.py0000755
./deluge/ui/console/commands/halt.py0000755
./deluge/ui/console/commands/info.py0000755
./deluge/ui/console/commands/add.pyc0000644
./deluge/ui/gtkui/torrentdetails.pyc0000644
./deluge/ui/gtkui/queuedtorrents.pyc0000644
./deluge/ui/gtkui/filtertreeview.pyc0000644
./deluge/ui/webui/page_decorators.py0000755
./deluge/ui/webui/torrent_options.py0000755
./deluge/ui/webui/lib/egg_handler.py0000755
./deluge/ui/webui/lib/egg_render.pyc0000644
./deluge/ui/webui/lib/webpy022/db.py0000755
./deluge/plugins/Label-0.1-py2.5.egg0000644
./deluge/plugins/webuipluginbase.pyc0000644
./deluge/data/pixmaps/checking16.png0000644
./deluge/data/pixmaps/inactive16.png0000644

Let's look also in the deluge tar archive:

box# tar tjvf deluge-1.1.5.tar.bz2 | grep 0000
-rw-r--r-- 0/0     21100 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/core/preferencesmanager.pyc0000644
-rwxr-xr-x 0/0      1079 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/quit.py0000755
-rwxr-xr-x 0/0      2299 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/help.py0000755
-rwxr-xr-x 0/0      1125 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/halt.py0000755
-rwxr-xr-x 0/0      5296 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/info.py0000755
-rw-r--r-- 0/0      2036 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/add.pyc0000644
-rw-r--r-- 0/0     13688 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/torrentdetails.pyc0000644
-rw-r--r-- 0/0      7346 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/queuedtorrents.pyc0000644
-rw-r--r-- 0/0     13073 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/filtertreeview.pyc0000644
-rwxr-xr-x 0/0      5062 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/page_decorators.py0000755
-rwxr-xr-x 0/0      3233 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/torrent_options.py0000755
-rwxr-xr-x 0/0      1553 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_handler.py0000755
-rw-r--r-- 0/0      1522 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_render.pyc0000644
-rwxr-xr-x 0/0     20480 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/webpy022/db.py0000755
-rw-r--r-- 0/0     38041 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/Label-0.1-py2.5.egg0000644
-rw-r--r-- 0/0      2982 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/webuipluginbase.pyc0000644
-rw-r--r-- 0/0       699 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/checking16.png0000644
-rw-r--r-- 0/0       595 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/inactive16.png0000644

At a first glance it seem that the archive is corrupted but when I tried the same operation on my mirror system (on the PC) no corrupted file appeared in the archive.
The difference was that while on the mirror system I have the GNU tar 1.20 installed, on the box there is a busybox version containing tar utility:

box# which tar
/bin/tar
box# ls -l /bin/tar
lrwxrwxrwx 1 root root 7 2008-05-21 13:40 /bin/tar -> busybox

I decided to build the newest GNU tar version (1.22) and install it to the box. A new post containing the build procedure will follow. After the installation the problem disappeared.

Socket related crash

I am not sure whether it was new to this version, but after the installation from time to time I have experienced a weird crash of the deluge daemon. Also the Windows client did not respond for long time when was connected to the daemon running on the box. After some experimenting with the deluge log I decided to debug the daemon to find out what is going on.
I was running the gdbserver on the box:

box# LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" gdbserver colinux:2345 `which python` `which deluged` -d
Process /usr/bin/python created; pid = 31831
Listening on port 2345
Remote debugging from host 192.168.1.102
...

Then I was ready to connect to the gdbserver from my mirror system:

deb# gdb `which python`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux-uclibc"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) target remote storage:2345
Remote debugging using storage:2345
0x40000c90 in ?? ()
(gdb) cont
Continuing.
...

After some time when I was connecting and disconnectiong the windows client to the daemon the problem appeared:

[New Thread 32801]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32801]
0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
108             size = strlen(str);
(gdb)

It was at the following stack:

(gdb) where
#0  0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
#3  0x40094bd2 in PyCFunction_Call (func=0x405ac70c, arg=0x40f2f48c, kw=0x0) at Objects/methodobject.c:108
#4  0x400dcf1a in PyEval_EvalFrameEx (f=0x81f8624, throwflag=0) at Python/ceval.c:3573
#5  0x400de1e6 in PyEval_EvalCodeEx (co=0x405b94e8, globals=0x405b624c, locals=0x0, args=0x820022c, argcount=1, kws=0x8200230, kwcount=0, defs=0x405be518, defcount=1,
    closure=0x0) at Python/ceval.c:2836
#6  0x400dd6d0 in PyEval_EvalFrameEx (f=0x82000e4, throwflag=0) at Python/ceval.c:3669
#7  0x400dda59 in PyEval_EvalFrameEx (f=0x81e77d4, throwflag=0) at Python/ceval.c:3659
#8  0x400de1e6 in PyEval_EvalCodeEx (co=0x405c13c8, globals=0x405b602c, locals=0x0, args=0x406200b0, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2836
...

a crash in PyString_FromString seems to be just a consequence, let's look up a bit:

(gdb) up
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
3048                            tmp = PyString_FromString(*pch);
(gdb) list
3043
3044            /* SF #1511317: h_aliases can be NULL */
3045            if (h->h_aliases) {
3046                    for (pch = h->h_aliases; *pch != NULL; pch++) {
3047                            int status;
3048                            tmp = PyString_FromString(*pch);
3049                            if (tmp == NULL)
3050                                    goto err;
3051
3052                            status = PyList_Append(name_list, tmp);
(gdb) print h
$1 = (struct hostent *) 0xbb9fdae8
(gdb) print *h
$2 = {h_name = 0xbb9f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbb9f9aec}
(gdb) print h->h_aliases
$3 = (char **) 0x40172891
(gdb) print *h->h_aliases
$4 = 0xc7c3815b <Address 0xc7c3815b out of bounds>

... It seems that a host entry should contain an array of strings - aliases - but this array is apparently corrupted - it causes a crash of the C string -> Python string conversion routine. Let's look who is responsible for filling the array:

(gdb) up
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) list
3268            PyThread_acquire_lock(netdb_lock, 1);
3269    #endif
3270            h = gethostbyaddr(ap, al, af);
3271    #endif /* HAVE_GETHOSTBYNAME_R */
3272            Py_END_ALLOW_THREADS
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
3274    #ifdef USE_GETHOSTBYNAME_LOCK
3275            PyThread_release_lock(netdb_lock);
3276    #endif
3277            return ret;

The gethostbyaddr seems as a good candidate. At first I wondered whether the function is thread safe (see the following text about uClibc thread safety), but after further debugging I have found out that the apparently thread safe variant gethostbyaddr_r is called in my case, so there should be not threading issue there.

(gdb) cont
Continuing.
[New Thread 1024]
Breakpoint 2 at 0x407e574c: file /usr/local/src/Python-2.5.2/Modules/socketmodule.c, li
Pending breakpoint "socket_gethostbyaddr" resolved
[New Thread 19476]
[Switching to Thread 19476]

Breakpoint 2, socket_gethostbyaddr (self=0x0, args=0x40f27ccc) at /usr/local/src/Python
3229            if (!PyArg_ParseTuple(args, "s:gethostbyaddr", &ip_num))
...
(gdb) next
3252            Py_BEGIN_ALLOW_THREADS
(gdb) next
3255            result = gethostbyaddr_r(ap, al, af,
(gdb) next
3272            Py_END_ALLOW_THREADS
(gdb) print buf
$12 = "À¨\001eè\232?½", '\0' <repeats 16 times>, "filodej.doma\000.in-addr.arpa", '\0' <repeats 16333 times>, "@"
(gdb) next
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) print *h
$14 = {h_name = 0xbd3f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbd3f9aec}
(gdb) print h->h_aliases
$15 = (char **) 0x40172891
(gdb) print *h->h_aliases
$16 = 0xc7c3815b <Address 0xc7c3815b out of bounds>

... after some googling I found some hints in the following forum.
Actually it seem there were two related bugs: the first in gethostbyname_r seems to be fixed now, steps to simply reproduce the problem:

box# python -c 'import socket; print socket.gethostbyname_ex("wh0rd.org")[2];'
['80.68.88.204']

... it was ok in my case, it seems to be fixed in 0.9.27 version.
The second bug is in gethostbyaddr_r function. The step to reproduce is following:

box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
Segmentation fault

... it crashes on my box. Given you have the Python installed, you can test your configuration the same way.
For the solution I decided not to patch or upgrade the uClibc but rather make a workaround in the python socket library. Zeroing the structure prior to the gethostbyaddr_r call should be enough. Let's modify the python Modules/socketmodule.c file. In the PySocket_gethostbyaddr functon there is a hp_allocated structure we are going to reset to zeroes. Just before the gethostbyaddr_r call we add the following code:

#if   defined(HAVE_GETHOSTBYNAME_R_6_ARG)
        memset((void *) &hp_allocated, '\0', sizeof(hp_allocated));
        result = gethostbyaddr_r(ap, al, af,
                &hp_allocated, buf, buf_len,
                &h, &errnop);

... and rebuild and re-pack the python package:

deb# cd /usr/local/src/Python-2.5.2
deb# make
case $MAKEFLAGS in \
*-s*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
running build
running build_ext
db.h: found (4, 3) in /mnt/C/sys/include
db lib: using (4, 3) db-4.3
/mnt/C/sys/include/sqlite3.h: version 3.5.8
INFO: Can't locate Tcl/Tk libs and/or headers
building '_socket' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/socketmodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lpython2.5 -o build/lib.linux-i686-2.5/_socket.so
building 'nis' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/nismodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lnsl -lpython2.5 -o build/lib.linux-i686-2.5/nis.so
*** WARNING: renaming "nis" since importing it failed: dynamic module does not define init function (initnis)
running build_scripts
box# make install
...
deb# cd /mnt/C/
deb# ./filopack.sh -R --pack python-2.5.2
...

Build process

The build process was identical to 1.1.0 version, I just had to create .pth link file in order to be able to remove the duplicate directories:

 
dev# cd /mnt/C/sys/lib/python2.5/site-packages
dev# echo "./deluge-1.1.5-py2.5-linux-i686.egg" > deluge.pth

dev# cd /mnt/C/
dev# ./filopack.sh --pack deluge-1.1.5

Remove all the "site-packages/deluge/" sub-paths (they seem to be redundant) and re-pack the package once more.

Port forwarding & Remote desktop connection (updated)

2009-03-26T20:37:00.004+01:00

Overview

In the company I am working as a developer we have relatively flexible rules how to organize working time (some workdays we can work from home assuming we are online and easily accessible by other team members). On the other side there are strict IT rules and firewall settings complicating the remote access.
The e-mail access and even the remote desktop access is officially possible just via a web portal provided that you withstand a tedious login process and unbearable refresh rate (not speaking of an odd interference with skype).
Thus we faced a challenge how to overcome the strict firewall settings and open up a direct (and swift) remote desktop access. Finally we succeeded, and in this post I am going to share the method with you, having possibly similar problems.

Info sources

[Secure remote access of a private network]
[Port forwarding for Remote Desktop]
[Unix man pages: ssh(1)]
[Concurrent Remote Desktop Sessions in Windows XP SP2]
[Speed up SSH X11 forwarding]
[SSH port forwarding]

Configuration

At home I have a PC workstation with Windows XP and laptop with Linux Ubuntu 8.04, both computers behind the Linksys router WRT54GL with DD-WRT firmware version 2.4.
In the office I have a PC workstation with Windows XP behind a firewall. The firewall is administered by the IT department (residing abroad) and developers have no way of configuring it.
The office firewall is configured that there are no incoming ports open and there are just a few outgoing: 80 (http), 119 (nntp), 1863 (msnp) and maybe few others I do not know of.
The goal is to find a way how to enable Remote desktop connection across the Internet in both directions.
We decided to use SSH port forwarding feature. Since the port 22 standardly used for SSH access is not forwarded on the firewall even for outgoing connections we had to use another port - 119 was our choice.
In following text I use port 119, actually it is specific to this specific scenario, given there is another firewall configuration, port selection has to be done correspondingly.

Homeward connection

This direction is a simpler one, since there are at least some ports open on the firewall for outgoing connections.
We have the following:

Home internet connection with public IP address

as an alternative you can use a dynamic DNS service (like dynDNS or similar) but also need a port forwarding for at least port 119 activated by your ISP

Home router with SSH access activated, but configured to listen on port 119
- In case you have no router you can have SSH service/daemon (configured for port 119) running directly on your computer
Home PC with OS Windows (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389
Home Laptop with OS Linux (Ubuntu Hardy 8.04) - VNC server screen 1 listening on port 5901
Office PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client) with VNC viewer installed.

Steps to establish the remote desktop connection:

Launch SSH client configured with following command line:
ssh.exe -L 3391:workstation:3389 -L 5951:laptop:5901 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Forwarding local port 3391 to port 3389 of remote host "workstation"
- Forwarding local port 5951 to port 5901 of remote host "laptop"
In order to connect to the Windows machine launch the Terminal services client:
mstsc.exe /v:localhost:3391
In order to connect to the Linux machine launch the VNC viewer:
vncviewer.exe localhost:5951

And that's it. Following schema demonstrates the whole situation:

This was a simpler direction (according to the firewall configuration). The more complicated one follows...

Connection towards Office

This direction is a more intricate one, simply because we are trying to go "against" the firewall, it is configured to disallow any incoming connection. So if we cannot connect to the office computer (sitting behind the firewall) what about turning over the problem to the previous (already solved) one? We could possibly be contacted by our office computer instead of trying contact it ourself.
But we still need some way to initiate the whole connection process. After all must be at least some how to pass through the firewall. If there is such facility, we could use it as our trigger (Surely there is such a facility - a good old e-mail ;-).
Now we have the following:

Office PC with OS Windows XP (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389 and Outlook client running with a custom e-mail rule starting the connection (we can define a rule for specific sender address, subject or body containing some "magic" string etc).
- Obviously any other e-mail client (with e-mail rules) can be used. Or it is possible to use another utility running as an OS service - this way it would be possible to contact the computer even when no user was previously logged in.
We still need an internet connection with public IP address or at least 119 incomming port forwarding (remember, even when we are connecting to the office - actually our ofice is contacting us ;)
Home router with SSH access activated, but configured to listen on port 119. Also we need to have the Office Workstation's rsa key added to the list of router's Authorized keys.
Home PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client). We can send the initiating e-mail by hand or prepare a script automating the whole connection process (I am using a python script since it can be used on Linux machine as well).
Home Laptop with OS Linux (Ubuntu Hardy 8.04) - can be used as a Terminal services client as well.

Steps to establish the remote desktop connection:

From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
- Forwarding port 3391 of the remote host (Home router) to local port 3389.
On either workstation or laptop we connect to the router with following command line:
ssh.exe -L 3391:localhost:3393 <user>@router
... which means:
- Connect to the router (via standard port 22) as a user <user>
- Forwarding local port 3391 to router's 3393 port
Establish the remote desktop connection to the Office Workstation.
- From Windows: MSTSC.EXE /v:localhost:3391
- From Linux: rdesktop localhost:3391 -u <user> -d <domain> -p -

Following schema demonstrates the whole sequence of events:
Note: not all steps are always necessary. The tunnel between Office Workstation and Home router can sometimes last for several days (while sometimes is spontaneously interrupted - it probably depends on a quality of Internet connection) and so it is not necessary to send the initiating e-mail anytime we want to connect to the office. So usually the first thing I do is to open the SSH connection to the router (step 3), determine whether there is the existing office connection (e.g. via ps command I look at the number of dropbear and sh instances) and if so proceed directly to the step 4.

Update - significant simplification

At the time I initially wrote this post I did not know why it was not possible to connect to the router's forwarded port from another host. That was why I created actually two tunnels (Office PC -> Router<- Home PC) when I was connecting remotely to the office.
After some time I have found some more info in this regard: Client side:

As a security precaution, modern versions of ssh forbid other computers on the internet from connecting to the forwarded port (...) unless you explicitly allow it with the "ssh -g" flag

Server side:

If the client is not configured to accept inbound SSH connections, this can be done with remote port forwarding on an outbound connection. (For OpenSSH, note that you may need to set "GatewayPorts yes" in "sshd_config" to achieve on the server what "ssh -g" would do on the client (allow any host to connect to the forwarded port).

Then I found some more info indicating that it does not work for DropBear even when properly configured (here and here):

The reason that the direct login to remote forwarded port doesn't work is - "dropbear binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports." To fix it, you can recompile dropbear for your router.

I did not want to rebuild dropbear for my router (I do not even have a build toolchain for it) so I kept trying. Finally I realized that when I explicitly use the actual hostname for my router (router in my configuration) instead of localhost (as used by default) on the remote port forwarding command line, it does the trick:
So - on the Office PC command line - instead of former:

ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa @ -p 119

Now I am using:

ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa @ -p 119

... and after this change it is possible to connect to the tunnel not only from the router itself but from any other machine in the network.
I did not consider possible security implications, after all I am just a simple user in this regard, so it is up to you to decide which approach better fits your needs, please, don't blame me then.

Steps to establish the remote desktop connection:

From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
... which means:
- Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
- Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
- Forwarding port 3389 of the remote host with hostname router" (Home router) to local port 3389.
On either workstation or laptop we establish the remote desktop connection to the Office Workstation as follows:
- From Windows:
```
MSTSC.EXE /v:router
```
- From Linux:
```
rdesktop router -u <user> -d <domain> -p -
```

Following schema demonstrates the whole sequence of events:

NX accelerated RDP

@TBD

WMU-6500FS - Deluge 1.1.0

2009-01-18T00:32:00.019+01:00

The new deluge version is here!

Build result

[binary] [file list]
If you don't have the previous version (deluge-1.0.5) installed, follow the previous deluge post, install all the prerequisites and dependencies and come back here for the rest. Note that the deluge-1.0.5-gcclibs package is valid even for deluge-1.1.0, so don't get confused with its misleading name.
On the other hand if you have the deluge-1.0.5 installed, you have to clean it up first (while preserve all the already installed dependencies).

Stop the deluge daemon if it is running. You can do it via console:

box# deluge --ui=null
>>> halt
>>> quit
Thanks!

or forcibly:

box# killall deluged

Now uninstall the previous version:

dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.0.5
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.0.5 locally at /mnt/C (y/n)?y
...

If you are not using the filopack packaging system, you can remove the previous version as follows:

box# cd /mnt/C/
box# wget http://filodej.ic.cz/filopack/.filopack/deluge-1.0.5.lst
box# xargs rm -f < deluge-1.0.5.lst

It is likely that deluge developers preserved the compatibility of configuration and the following step is not necessary, I just to be sure delete the configuration as well:

box# mv ~/.config/deluge{,.del}

Now we are ready to install the new version:

box# ./filopack.sh --install deluge-1.1.0
Sure to unpack deluge-1.1.0 locally at /mnt/C (y/n)? y
...

Now we are ready to try the daemon, still it is necessary to use the LD_PRELOAD prefix or deluged.sh script - now updated in order to support parameters (like -d for example) - see this post on mascat for details - if we are lucky, everything runs smoothly:

box# deluged.sh

Default GUI

It is possible to set a default GUI (if you prefer other than predefined GTK GUI):

box# deluge --set-default-ui=console
The default UI has been changed to console

It is nice that now it is not necessary to modify the configuration by hand (like it is described here).

Remote access

The CLI ui has been renamed from null to console. Notice that it is necessary to use LD_PRELOAD prefix just for daemon and GTK GUI, there is no need to use it for the console UI).
We can use it for enabling the remote access (we have to restart the daemon in order to make the change active):

box# deluge --ui=console
>>> config --set allow_remote True
>>> halt
>>> quit
Thanks!

box# deluged.sh

Authentication

Another new feature is the user authentication. For details see [Authentication] and [ThinClient settings]. Without adding a username and password to ~/.config/deluge/auth configuration file you won't be able to remotely connect to the daemon nor event see whether the daemon is running (which is a nice).

Edit: since the ~/.config/deluge/auth file initially does not contain trailing newline the instructions did not work, now it is updated appropriately

box# echo -n -e "\n<username>:<password>" >> ~/.config/deluge/auth

Be sure to append to the file, in case you rewrote the file you won't have been able to connect to it locally, since it initially contains a localclient record. If you accidentally rewrite the file, you can just delete it, restart the daemon and a ui (e.g. the console) and the default file containing localclient authentication info is created for you.

Web GUI

If you want to use the Web GUI (and new Ajax UI seems pretty good to me), now it is not necessary to run the web client on the same machine as daemon. Via the Web GUI you can connect to any daemon you want (not just localhost). Not sure whether I personally utilize it, but it seems to me like a nice feature.

That's all folks.
(The following text is just a (boring) build protocol, totally unnecessary for ordinary users ;-)

Build sequence

It was about the same like in previous version so just in short:

Remove the previous version:

dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.0.5
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.0.5 locally at /mnt/C (y/n)?y
...

Init the timestamp for the new one:

dev# ./filopack.sh --init  deluge-1.1.0
Configuration file .filopack/.config file found and used
Timestamp written to file .filopack/deluge-1.1.0.ts

Download and extract the source:

dev# cd /usr/local/src
dev# wget http://download.deluge-torrent.org/source/1.1.0/deluge-1.1.0.tar.bz2
...
04:37:59 (55.28 KB/s) - `deluge-1.1.0.tar.bz2' saved [2196924/2196924]

dev# tar xjvf deluge-1.1.0.tar.bz2
dev# cd deluge-1.1.0

Setup the include and library paths:

dev# export CFLAGS=-I/mnt/C/sys/include/boost-1_35
dev# export LDFLAGS=-L/mnt/C/sys/lib

Add the missing define:

nano libtorrent/include/libtorrent/socket.hpp

      #ifndef IPV6_V6ONLY
      #define IPV6_V6ONLY 26
      #endif

I did not find the libtorrent/src/memdebug.cpp, so undefining the content of this file is not necessary anymore.

Build the code and install the binaries:

dev# python setup.py build
...
dev# python setup.py install --prefix=/mnt/C/sys/
...

Try to run the daemon:

dev# deluged
dev# /usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

... issue wit h unresolved symbol is still the same. As a workaround the LD_PRELOAD prefix can be used. Let;s create scripts for it:

dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" deluged \"\$@\" > /mnt/C/sys/bin/deluged.sh
dev# chmod +x /mnt/C/sys/bin/deluged.sh 
dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" deluge \"\$@\" > /mnt/C/sys/bin/deluge.sh
dev# chmod +x /mnt/C/sys/bin/deluge.sh

Now the daemon runs ok:

dev# deluged.sh

Let's try the GTK client:

dev# deluge --version
1.1.0
dev# deluge
...
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.1.0-py2.5-linux-i686.egg/deluge/ui/gtkui/common.py", line 

45, in get_logo
    size, size)
gobject.GError: Unrecognized image file format

ChangeAs a fix we can change the extension:

dev# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/lib/python2.5/site-packages/deluge/ui/gtkui/common.py
dev# deluge

Touch related files with older timestamps (in order to include them to the package):

dev# find /mnt/C/sys -path "*deluge*" -type f -exec touch {} \;

Then we are ready to create the package:

dev# cd /mnt/C/sys
dev# ./filopack.sh --pack deluge-1.1.0
...

I noticed that there was duplicity after the installation which made the package twice as big as was necessary: It seems to me that whole directory tree /mnt/C/sys/lib/python2.5/site-packages/deluge-1.1.0-py2.5-linux-i686.egg/deluge was redundant - directory /mnt/C/sys/lib/python2.5/site-packages/deluge had a similar content (including the huge libtorrent.so). I just dropped the former one and everything seems ok and package has 16MB (compared to 31MB).

Cooperative Linux step by step

2009-01-06T23:33:00.027+01:00

Introduction:

This post provides a step by step tutorial how to download, install and configure CoLinux with Debian 4.0 file system image. Also the installation of GNOME desktop environment and NX server is covered. As a result we get a graphic Linux environment cooperatively running on the Windows hosting system. It can be seen as an alternative to a conventional "dual boot" configuration - but with both systems running at the same time.

Info sources:
[CoLinux Homepage] [CoLinux Wiki]

[Debian notes] [Debian filesystem image] [More available filesystem images] [Howto install coLinux (and Ubuntu Hardy) on Win XP]

Download and installation

CoLinux binary
You can download binary here.
In my case it was the stable version 0.7.3 (kernel 2.6.22.18) ... coLinux-0.7.3.exe
(an alternative could be the development version 8.0 (kernel 2.6.22.18) ... devel-coLinux-20081130.exe, see this page for details).

Selected components: During the installation the WinPcap (The Windows Packet Capture Library) is installed. It can be downloaded here.

I choose stable WinPcap 4.0.2 (an alternative could be WinPcap 4.1 beta4). We can download (some of) available filesystem images directly during the installation: TAP network adapter is installed (dear Microsoft, sure we want to continue the installation ;-) Now the TAP adapter is installed (but not connected): We have to configure the private IP address of the host system (windows):

Installation paths:
CoLinux binary: c:\programs\coLinux
Filesystem images: c:\programs\coLinux\images

Configure (Windows side)

Config file
We create a new configuration file (just modify the installed example.conf):

C:\> cd programs\coLinux
C:\programs\coLinux> copy example.conf debian.conf
        1 file(s) copied.
C:\programs\coLinux> notepad debian.conf

Now we can specify root image, swap file and possibly other mount points and also define two ethernet devices - one for pcap bridge and second for TAP adapter:

...

# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cofs1=c:\
cofs2=d:\

# Swap device, should be an empty file with 128..512MB.
cobd1="C:\programs\coLinux\images\swap_file.1gb"

# Tell kernel the name of root device (mostly /dev/cobd0,
# /dev/cobd/0 on Gentoo)
# This parameter will be forward to Linux kernel.
root=/dev/cobd0

# Additional kernel parameters (ro = rootfs mount read only)
ro

# Initrd installs modules into the root file system.
# Need only on first boot.
initrd=initrd.gz

# Maximal memory for linux guest
#mem=64

# Slirp for internet connection (outgoing)
# Inside running coLinux configure eth0 with this static settings:
# ipaddress 10.0.2.15   broadcast  10.0.2.255   netmask 255.255.255.0
# gateway   10.0.2.2    nameserver 10.0.2.3
#eth0=slirp

# pcap bridge for internet connection (outgoing)
eth0=pcap-bridge,"Local Area Connection",<an-artificial-mac-address>

# Tuntap as private network between guest and host on second linux device
eth1=tuntap

# Setup for serial device
#ttys0=COM1,"BAUD=115200 PARITY=n DATA=8 STOP=1 dtr=on rts=on"

# Run an application on colinux start (Sample Xming, a Xserver)
# exec0=C:\Programs\Xming\Xming.exe,":0 -clipboard -multiwindow -ac"

Swap file
Also you have to create a swap file, here is how to create it, or if you are lazy like me, you can download one from this site (user Gniarf provides also other interesting info).

Configure (Linux side)

Start colinux daemon:

C:\programs\coLinux> colinux-daemon.exe @debian.conf
Cooperative Linux Daemon, 0.7.3
Daemon compiled on Sat May 24 22:36:07 2008

PID: 3268
error 0x2 in execution
error launching console
daemon: exit code 8200c401
daemon: error - CO_RC_ERROR_ERROR, line 49, file src/colinux/os/winnt/user/exec.c (16)

We did not install the generic console so we have to explicitly say we want to launch the NT console:

C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...

login as: root
root@10.0.2.2's password:
Linux debian 2.6.22.18-co-0.7.3 #1 PREEMPT Sat May 24 22:27:30 UTC 2008 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Change the root password

deb# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Network
For easy to use the network is pre-configured for "slirp":

deb# ifconfig
eth0      Link encap:Ethernet  HWaddr 22:01:76:23:42:12
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:20682 (20.1 KiB)  TX bytes:0 (0.0 b)
          Interrupt:2

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

We change it to dual-ethernet mode (one for uoutide world connection and other for private network between guest and host system):

deb# nano /etc/network/interfaces

Comment out the following:

    # The primary network interface (slirp)
    auto eth0
    iface eth0 inet static
       address 10.0.2.15
       broadcast 10.0.2.255
       netmask 255.255.255.0
       gateway 10.0.2.2

And replace it with following:

    # The primary network interface
    auto eth0
    iface eth0 inet dhcp

Then there is the following:

    # Second network (tap-win32)
    #auto eth1
    #iface eth1 inet static
    #   address 192.168.0.40
    #   netmask 255.255.255.0

... leave it as is (or remove it) and add the following:

    auto eth1
    iface eth1 inet static
       address 10.0.2.2
       network 10.0.2.0
       netmask 255.255.255.0
       broadcast 10.0.2.255

Now save the file and reboot:

deb# reboot
...

We should see now on the Windows side that the TAP adapter is connected: After we login to linux, we can examine the new network configuration:

deb# ifconfig
eth0      Link encap:Ethernet  HWaddr <an-artificial-mac-address>
          inet addr:192.168.1.196  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11031 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24760203 (23.6 MiB)  TX bytes:770417 (752.3 KiB)
          Interrupt:2

eth1      Link encap:Ethernet  HWaddr 00:FF:68:B7:70:00
          inet addr:10.0.2.2  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2238 (2.1 KiB)  TX bytes:0 (0.0 b)
          Interrupt:2

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Packaging system
Now (we are connected to the internet) it is time to update the package system and upgrade installed packages:

deb# apt-get update
...
deb# apt-get upgrade
The following packages will be upgraded:
  bsdutils cpio debconf debconf-i18n debian-archive-keyring dpkg e2fslibs
  e2fsprogs findutils initscripts libblkid1 libc6 libcomerr2 libgnutls13
  libpam-modules libpam-runtime libpam0g libss2 libuuid1 lsb-base mount nano
  perl-base sysv-rc sysvinit sysvinit-utils tar tzdata util-linux
29 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.3MB of archives.
After unpacking 1786kB disk space will be freed.
Do you want to continue [Y/n]? Y
...

Mount table
Now we can modify the mount table:

deb# nano /etc/fstab

... add the following if you want to mount C: and D: windows drives (we made it available as cofs devices in debian.conf file):

cofs1            /mnt/c         cofs    defaults,noatime  0      0
cofs2            /mnt/d         cofs    defaults,noatime  0      0

Of course you can add anything you want, for example I wanted to make a cifs mount to a NAS directory:

//storage/filodej   /mnt/storage/filodej   cifs defaults,credentials=/etc/storage.smbpass 0 0

The storage-filodej.smbpass is a file readable just by root and containing a username and his password:

deb# cd /etc
deb# echo "username=filodej" > storage.smbpass
deb# chmod 600 storage.smbpass
deb# echo "password=<filodej-password>" >> storage.smbpass
deb# cat storage.smbpass
username=filodej
password=<filodej-password>

Now we have to create corresponding mount point directories:

deb# cd /mnt
deb# mkdir c
deb# mkdir d
deb# mkdir --parents storage/filodej

Test the mount table:

deb# mount -a
mount: wrong fs type, bad option, bad superblock on //storage/filodej,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

It seems I forgot to to install the samba file system:

deb# apt-get install smbfs

Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libkrb53 libpopt0 samba-common
Suggested packages:
  krb5-doc krb5-user smbclient
The following NEW packages will be installed:
  libkrb53 libpopt0 samba-common smbfs
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3232kB of archives.
After unpacking 7827kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...

During the installation we have to specify the Domain/Workgroup name and decide whether to use WINS settings from DHCP (and install dhcp3-client package).

Now the command:

deb# mount -a

... works as expected.

Install CoLinux as a Windows Service

We need to be able to access the running linux system somehow. I am using mostly the SSH for that purpose.
First we have to install ssh daemon it on the linux system:

deb# apt-get install ssh
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libedit2 libssl0.9.8 openssh-blacklist openssh-client openssh-server
Suggested packages:
  ssh-askpass xbase-clients rssh molly-guard
The following NEW packages will be installed:
  libedit2 libssl0.9.8 openssh-blacklist openssh-client openssh-server ssh
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 5779kB of archives.
After unpacking 12.7MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
Setting up ssh (4.3p2-9etch3) ...

deb# eth0: duplicate address detected!

The duplicate address detected! issue is described here.
I have associated the <an-artificial-mac-address> with static-DHCP assigned IP but the warning stil does persist. If anyone knows the solution, please let me know!

Anyway the ssh daemon is now up and running and we are able to connect to the linux system via ssh (on the host machine we can use either eth0 public IP or better the eth1 private IP). Now we are ready to create a windows service and run the colinux as a service.

The detailed guide for the service creation can be seen here. The following command does the job:

C:\programs\coLinux> colinux-daemon @debian.conf --install-service "coLinux-Debian"
Cooperative Linux Daemon, 0.7.3
Daemon compiled on Sat May 24 22:36:07 2008

daemon: installing service 'coLinux-Debian'
daemon: service command line: "c:\programs\coLinux\colinux-daemon.exe" @debian.conf --run-service "coLinux-Debian"
daemon: setting restart options
daemon: service installed.

Now we can start colinux daemon as a service:

C:\programs\coLinux> net start "coLinux-Debian"

The coLinux-Debian service was started successfully.

Linux administration

Create a new user
[Add user howto]

deb# adduser --home /home/filodej --ingroup users filodej
Adding user `filodej' ...
Adding new user `filodej' (1001) with group `users' ...
Creating home directory `/home/filodej' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for filodej
Enter the new value, or press ENTER for the default
        Full Name []: Filodej
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [y/N] y

Install sudo
[linux sudo command]

deb# apt-get install sudo
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  sudo
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.
Need to get 162kB of archives.
After unpacking 406kB of additional disk space will be used.
Get:1 http://ftp.debian.org etch/main sudo 1.6.8p12-4 [162kB]
Fetched 162kB in 1s (95.8kB/s)
Selecting previously deselected package sudo.
(Reading database ... 25225 files and directories currently installed.)
Unpacking sudo (from .../sudo_1.6.8p12-4_i386.deb) ...
Setting up sudo (1.6.8p12-4) ...
No /etc/sudoers found... creating one for you.

Let's look at the sudoers definition file:

deb# cat /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

Now we can make the new user sudoer:

deb# visudo
...

Let's look at the result:

deb# cat /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification
filodej    ALL=(ALL) ALL

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

Resize the root filesystem

[Expanding root filesystem howto]

I decided for the most reliable way.
First we look at the current filesystem:

deb# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             1031064    197876    780812  21% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44298800 111981488  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej

Now we halt the system (if we are logged as a normal user, we have to use sudo):

deb# sudo halt
...
Broadcast message from root@debian (pts/2) (Wed Dec 10 05:11:48 2008):

The system is going down for system halt NOW!

On windows we now go to the images directory:

C:\> cd programs\coLinux\images

C:\programs\coLinux\images> dir
 Volume in drive C has no label.
 Volume Serial Number is F488-7A65

 Directory of C:\programs\coLinux\images

01/06/2009  21:49    <DIR>          .
01/06/2009  21:49    <DIR>          ..
01/06/2009  20:29     1,072,693,248 Debian-4.0r0-etch.ext3.1gb
03/27/2008  19:59        40,795,971 Debian-clean.1gb.bz2
12/22/2008  22:32     1,073,741,824 swap_file.1gb
               3 File(s)  2,187,231,043 bytes
               2 Dir(s)  124,332,199,936 bytes free

Now make a backup copy of the old filesystem:

C:\programs\coLinux\images> copy Debian-4.0r0-etch.ext3.1gb Debian-4.0r0-etch.ext3.1gb.tmp
        1 file(s) copied.

Create a new (empty) file (e.g. 8GB in this case):

C:\programs\coLinux\images> fsutil file createnew Debian-4.0r0-etch.ext3.8gb 8589934592
File C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb is created

Let's list the images directory again:'

C:\programs\coLinux\images> dir
 Volume in drive C has no label.
 Volume Serial Number is F488-7A65

 Directory of C:\programs\coLinux\images

01/06/2009  22:02    <DIR>          .
01/06/2009  22:02    <DIR>          ..
01/06/2009  13:07     1,072,693,248 Debian-4.0r0-etch.ext3.1gb
01/06/2009  20:29     1,072,693,248 Debian-4.0r0-etch.ext3.1gb.tmp
01/06/2009  22:02     8,589,934,592 Debian-4.0r0-etch.ext3.8gb
03/27/2008  20:59        40,795,971 Debian-clean.1gb.bz2
01/06/2009  22:02                 0 fsutil
12/22/2008  22:32     1,073,741,824 swap_file.1gb
               6 File(s) 11,849,858,883 bytes
               2 Dir(s)  114,669,043,712 bytes free

Now we can modify the debian.conf configuration file as follows:

C:\programs\coLinux\images> cd ..

C:\programs\coLinux> notepad debian.conf

Add the two newly created file images as block devices:

# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cobd3="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb.tmp"
cobd4="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb"
cofs1=c:\
cofs2=d:\

Now we can boot the colinux up and login as root:

C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...
debian login: root
Password:
...
deb#

Now we check if the the copy of the old filesystem is clean:

deb# e2fsck /dev/cobd3
e2fsck 1.40-WIP (14-Nov-2006)
/dev/cobd3: clean, 8967/131072 files, 53582/261888 blocks

If we now try to check the empty image, we (presumably) get the error:

deb# e2fsck /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/cobd4

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Let's copy the raw data from the old image to the new:

deb# dd if=/dev/cobd3 of=/dev/cobd4
2095104+0 records in
2095104+0 records out
1072693248 bytes (1.1 GB) copied, 110.632 seconds, 9.7 MB/s

Now we can check the filesystem (-f will force checking even if filesystem is marked clean):

deb# e2fsck -f /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/cobd4: 8967/131072 files (0.6% non-contiguous), 53582/261888 blocks

Let's resize the filesystem from 1GB to 8GB:

deb# resize2fs -p /dev/cobd4
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/cobd4 to 2097152 (4k) blocks.
Begin pass 1 (max = 56)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/cobd4 is now 2097152 blocks long.

... and check it again:

deb# e2fsck -f /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/cobd4: 8967/1048576 files (0.6% non-contiguous), 82374/2097152 blocks

Now we are almost done and can halt the system:

deb# halt

In windows we can modify the debian.conf configuration file again:

C:\programs\coLinux> notepad debian.conf

Remove the two newly block devices and change the root file system to Debian-4.0r0-etch.ext3.8gb:

# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
#cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb"
cofs1=c:\
cofs2=d:\

Now we can boot the colinux up and login:

C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...
debian login: root
Password:
...
deb#

Now we can inspect the free space we have:

deb# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             8256952    197876   7723532   3% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44281916 111998372  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej

We are done for now, if everything goes fine we can possibly delete both the original image and its temporary copy.

GNOME installation

[HOWTO: Minimal Debian Install (GNOME/KDE)]
[Installing x server]
You have to decide what display manager and Desktop environment to install.

Following table shows the numbers of packages and download and intallation sizes for "core" and "full" variations of mainstream environments GDM/GNOME and KDM/KDE:

	# packages	Archive size	Additional disk space
xorg	109	54.6 MB	143 MB
xorg + gnome-core	274	142 MB	461 MB
xorg + gnome	472	300 MB	931 MB
xorg + kde-core	208	120 MB	318 MB
xorg + kde	543	312 MB	830 MB

I decided to try "full" GNOME installation:

deb# apt-get install xorg gnome
...
0 upgraded, 472 newly installed, 0 to remove and 0 not upgraded.
Need to get 300MB of archives.
After unpacking 931MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...

... during the relatively lenthy process of the installation (on my machine it was 30 minutes for downloading and 15 minutes of installation) the xserver-xorg is configured and we are asked for desired screen resolutions. We are going to uninstall this package anyway so I do not think the settings we choose have any significant effect.

After the installation is finished we can inspect the free space:

debian:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             8256952   1430612   6490796  19% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44284428 111995860  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej

... and see that (as expected) the amount of used space on the root filesystem actually risen by approximately 1.2 GB.

NX server

[NX technology] [FreeNX] [A look at NoMachine NX] [NoMachine NX server free edition] [Installing NoMachine NX server] [NX keyboard shortcuts]
The following is written about the licensing model of NX technology on wikipedia:

NoMachine uses the GNU General Public License for the core NX technology, while at the same time offering non-free commercial NX server[2] and client products for Linux, Microsoft Windows, Solaris, Mac OS X and embedded systems.

Due to the free software nature of NX, the FreeNX project was started in order to provide the wrapper scripts for the GPL NX libraries. FreeNX is developed and maintained by Fabian Franz.

FreeNX server
At first I tried to install the FreeNX on my Laptop with Ubuntu installation but did not succeed. I used this and this tutorial, everything went fine, the only thing that did not work was the shadow session from windows client.
Every time I was connecting in shadow mode from windows client, nxagent on server side crashed:

Dec 19 17:08:23 notas kernel: [53641.720283] nxagent[5639]: segfault at 0000002c eip 080e9137 esp bff23b50 error 6

I tried to uninstall compiz (as someone advised) but it did not help. Maybe it was due to the client/server version incompatibility (I have used newer version of NoMachine windows client). As a result I decided to try the NoMachine NX server (free edition). It is limited for only two users or two simultaneous connections to the server, but this limitation was not so significant for me.

NoMachine NX server
If you are using "full" GNOME installation then the first thing I would recommend to do is to install the CUPS print server. The reasons are described here (the issue was not necessarily connected with NX server, but also NX server complained when the CUPS was not installed):

deb# apt-get install cupsys
...

Now we can proceed to the actual installation.

The NX Free Edition for Linux can be downloaded from this page. The release I am using is 3.3.0-8.

For the installation of NX server I have followed this tutorial.
We will need three packages: nxclient, nxnode and nxserver:

deb# cd /tmp
deb# wget http://64.34.161.181/download/3.3.0/Linux/nxclient_3.3.0-3_i386.deb
...
Length: 3,859,966 (3.7M) [application/x-debian-package]
...
deb# wget http://64.34.161.181/download/3.3.0/Linux/nxnode_3.3.0-3_i386.deb
Length: 6,251,244 (6.0M) [application/x-debian-package]
deb# wget http://64.34.161.181/download/3.3.0/Linux/FE/nxserver_3.3.0-8_i386.deb
...
Length: 6,717,880 (6.4M) [application/x-debian-package]
...

First we have to install the client (even if we are was not going to use it):

deb# dpkg -i nxclient_3.3.0-3_i386.deb
Selecting previously deselected package nxclient.
(Reading database ... 53454 files and directories currently installed.)
Unpacking nxclient (from nxclient_3.3.0-3_i386.deb) ...
Setting up nxclient (3.3.0-3) ...
Showing file: /usr/NX/share/documents/client/cups-info

 CUPS Printing Backend

 The NX Client set-up procedure detected that your "IPP CUPS" printing
 backend doesn't allow printing from the NX session. In order to have
 printing support in your NX system, you need to set proper permissions
 on the IPP backend. Please execute:

   chmod 755 /usr/lib/cups/backend/ipp

Ok, let's do what we are told:

deb# chmod 755 /usr/lib/cups/backend/ipp

Then the nxnode has to be installed:

deb# dpkg -i nxnode_3.3.0-3_i386.deb
Selecting previously deselected package nxnode.
(Reading database ... 55884 files and directories currently installed.)
Unpacking nxnode (from nxnode_3.3.0-3_i386.deb) ...
Setting up nxnode (3.3.0-3) ...
NX> 700 Starting: install node operation at: Tue Jan 06 12:08:11 2009.
NX> 700 Autodetected system 'debian'.
NX> 700 Install log is '/usr/NX/var/log/install'.
NX> 700 Checking NX node configuration using /usr/NX/etc/node.cfg file.
NX> 700 Inspecting local CUPS environment.
NX> 700 Generating CUPS entries in: /usr/NX/etc/node.cfg.
NX> 700 Installation of version: 3.3.0-3 completed.
NX> 700 Showing file: /usr/NX/share/documents/node/cups-info

     CUPS Printing Backend

     The NX Node setup procedure could not detect your "CUPS"
     installation: either CUPS  is not installed on your system
     or it was installed in a non-standard path. CUPS is needed
     in order to enable printing support in your NX system.
     Please note that you can enable  printing support for your
     NX system at any time; to do this make sure  that you have
     CUPS installed then run:

       /usr/NX/scripts/setup/nxnode --nxprintsetup 

     to specify the location of the CUPS root path.

... the CUPS related warning is hopefully not there if you have the CUPS server installed. If the warning is still there, the solution is simple:

deb# /usr/NX/scripts/setup/nxnode --nxprintsetup
NX> 701 Starting: nxprintsetup operation at: Mon Jan 05 13:14:31 2009.
NX> 701 Inspecting local CUPS environment.
NX> 701 Generating CUPS entries in: /usr/NX/etc/node.cfg.
NX> 701 CUPS configuration updated.

The last step is to install the nxserver itself:

deb# dpkg -i nxserver_3.3.0-8_i386.deb
Selecting previously deselected package nxserver.
(Reading database ... 56081 files and directories currently installed.)
Unpacking nxserver (from nxserver_3.3.0-8_i386.deb) ...
Setting up nxserver (3.3.0-8) ...
NX> 700 Installing: server at: Tue Jan 06 12:09:23 2009.
NX> 700 Autodetected system: debian.
NX> 700 Install log is: /usr/NX/var/log/install.
NX> 700 Creating configuration file: /usr/NX/etc/server.cfg.
NX> 723 Cannot start NX statistics:
NX> 709 NX statistics are disabled for this server.
NX> 700 Version '3.3.0-8' installation completed.
NX> 700 Showing file: /usr/NX/share/documents/server/install-notices

Server keys

The initial login between client and server happens through a DSA key
pair, i.e. a couple of specially generated cryptographic keys, called
the private key and the public key, which allow you to establish a
secure connection, by means of SSL encryption, between NX client and
NX server.

The public part of the key-pair is provided during the installation
of the server, while the private part of the key-pair is distributed
together with the NX Client. This ensures that each NX client is able
to authenticate to the server and to start the procedure for autho-
rizing the user and negotiating the session.

If you want to create a virtual private network (VPN) instead, you
need to generate a new DSA key-pair and distribute the private part
of the key-pair to those NX clients you want authenticated to the NX
server. More information on how to generate and distribute a new DSA
key-pair is available at:

http://www.nomachine.com/ar/view.php?ar_id=AR01C00126

Creating Users

NX is configured to allow access from any system user, as long as
valid credentials are given to the user for the SSH login. NX pro-
vides an alternative authorization method, allowing system admin-
istrators to determine which users are given access to the NX fun-
ctionalities. This works by implementing a separation between the
system password and the NX password, so that, for example, it is
possible to forbid remote access to the system by any other means
except via NX and use the NX tools to implement effective accounting
of the system resources used by the user, or to share NX passwords in
an external database.

To activate the NX user and password DBs, you will have to edit the
NX server configuration file by hand or use the NX Server Manager
Web tool available for download on the NoMachine Web site at:

http://www.nomachine.com/download-manager.php

Session Shadowing and Desktop Sharing

The session shadowing functionality allows you to share NX sessions
running on the node. The desktop sharing functionality instead, gives
access to the native display of the X server as if you were in front
of the monitor. By default you can access sessions in interactive mode
and upon authorization of the session owner. You can modify this beha-
viour by tuning the server configuration according to your needs, for
example by allowing access to sessions in view-only mode, or connecting
to either a suspended session or the local display via the Desktop
Manager login window.

Load Balancing

NX Advanced Server provides support for multi-node capabilities and
load balancing. In its current implementation, NX server can only
manage accounts on the host machine, so to grant access to the node
running remotely, you will need to create the user account directly
on the remote node host by issuing the NX node commands as root user.
You will also need to add the NX Server public DSA Key to the node to
allow this server to connect to the node running on the remote host.

Documentation

For further information on how to manage the configuration of your
NX system, please refer to the System Administrator's Guide available
on the NoMachine Web site at:

http://www.nomachine.com/documentation/admin-guide.php

The NoMachine Team.

NX> 700 Bye.

NX Client for Windows
NX Client for Windows can be downloaded from this page. Its installation is straightforward.

NX Connection wizard
With help of the NX connection wizard we can create a new session (if we are on local machine we can use the private TAP ethernet address): Here we choose a desktop environment (Gnome in this case) and a resolution: In advanced configuration we can modify everything we setup so far and much more: If we are on local machine I would recommend to disable image compression (icons and images then look better): We save the session settiongs and proceed to login dialog: The first time we are asked to story the RSA fingerprint (there is SSH running under the covers): Now we are succesfully connected to a new Gnome session:

Issues

X server start failure at boot time

When we reboot from the console we realize that X server is (unsuccesfully) started during the boot process: Actually we do not need xserver running on the coLinux side, we are going to connect via the NX server or use an X server running on the Windows side. As a solution we can uninstall the unnecessary gdm and xserver-xorg.

I admit that this install/uninstall approach seems weird, but currently I do not know a better solution, when I tried to just install the gnome without xorg the nxclient connection did not succeed. If someone with better knowledge of GNOME/X server/NX server dependencies knows a better approach, please, let me know.

Anyway, let's remove the GDM for now:

deb# apt-get remove gdm
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  fast-user-switch-applet gdm gdm-themes gnome gnome-desktop-environment
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 17.4MB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 52440 files and directories currently installed.)
Removing gnome ...
Removing gnome-desktop-environment ...
Removing fast-user-switch-applet ...
Removing gdm-themes ...
Removing gdm ...
Stopping GNOME Display Manager: gdm.

... and also the xserver:

deb# apt-get remove xserver-xorg
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all
  xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse
  xserver-xorg-input-synaptics xserver-xorg-video-all xserver-xorg-video-apm
  xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips
  xserver-xorg-video-cirrus xserver-xorg-video-cyrix xserver-xorg-video-dummy
  xserver-xorg-video-fbdev xserver-xorg-video-glint xserver-xorg-video-i128
  xserver-xorg-video-i740 xserver-xorg-video-i810 xserver-xorg-video-imstt
  xserver-xorg-video-mga xserver-xorg-video-neomagic
  xserver-xorg-video-newport xserver-xorg-video-nsc xserver-xorg-video-nv
  xserver-xorg-video-rendition xserver-xorg-video-s3
  xserver-xorg-video-s3virge xserver-xorg-video-savage
  xserver-xorg-video-siliconmotion xserver-xorg-video-sis
  xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-tga
  xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l
  xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-via
  xserver-xorg-video-vmware xserver-xorg-video-voodoo
0 upgraded, 0 newly installed, 44 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 19.3MB disk space will be freed.
Do you want to continue [Y/n]? Y
...

...and reboot to make sure the boot-up startx problem is gone.

Screensaver draining the CPU
The default GNOME screensaver "Floating Debian" was relatively CPU greedy. I disabled it and choose the "Blank screen" ( Desktop -> Preferences -> Screensaver ).

Gnome stopped responding
Initially I ran the GNOME and had not the CUPS server installed. Everything went fine but after few days a problem emerged. When I logged in desktop environment after some time (typically couple dozens of seconds) it stopped responding.
When I tried to start gnome session directly from console (using XMing server), there was the same problem, but fortunately the following warning appeared on the console just about the same time the desktop stopped responding:

deb# gnome-session
...
** (gnome-cups-icon:6107): WARNING **: Could not start the printer tray icon, because the CUPS server could not be contacted.

The issue is very similar to this (unresolved) one.
It is likely that the issue is not connected with NX server, but it is a coincidence that also the NX server installation complained about the fact that the CUPS server was not installed.
As a solution I decided to install the CUPS server:

deb# apt-get install cupsys
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  cupsys-common libslp1 poppler-utils
Suggested packages:
  cupsys-bsd cupsys-driver-gutenprint cupsys-driver-gimpprint
  foomatic-filters-ppds xpdf-korean xpdf-japanese xpdf-chinese-traditional
  xpdf-chinese-simplified cups-pdf hplip slpd openslp-doc
Recommended packages:
  cupsys-client smbclient foomatic-filters
The following NEW packages will be installed:
  cupsys cupsys-common libslp1 poppler-utils
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2604kB of archives.
After unpacking 12.1MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...

The installation complained about non-multicasting kernel, but hopefully it will not be a big problem:

To reduce network traffic use a IP multicast enabled kernel

The kernel version that you are currently running does not appear to     
support IP multicast. OpenSLP will continue to work even without
multicast support in the kernel by using broadcasts. However, broadcasts 
are less efficient on the network, so please consider upgrading to a
multicast enabled kernel.

Missing fonts
When I run emacs the following error appeared:

deb# emacs
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Warning: Cannot convert string "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1" to type FontStruct

... and the emacs application looked as follows:
The XOrg configuration seemed ok:

deb# cat /etc/X11/xorg.conf | grep FontPath
        FontPath        "/usr/share/fonts/X11/misc"
        FontPath        "/usr/share/fonts/X11/cyrillic"
        FontPath        "/usr/share/fonts/X11/100dpi/:unscaled"
        FontPath        "/usr/share/fonts/X11/75dpi/:unscaled"
        FontPath        "/usr/share/fonts/X11/Type1"
        FontPath        "/usr/share/fonts/X11/100dpi"
        FontPath        "/usr/share/fonts/X11/75dpi"
        FontPath        "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"

... the font paths really exist and contain the corresponding fonts:

deb# find /usr/share/fonts/X11/ -name *helv*
/usr/share/fonts/X11/100dpi/helvB08.pcf.gz
/usr/share/fonts/X11/100dpi/helvB10.pcf.gz
/usr/share/fonts/X11/100dpi/helvB12.pcf.gz
...

Really, there were some fonts matching the font name patterns:

deb# xlsfonts -fn '-*-helvetica-medium-r-*-*-*-120-*-*-*-*-iso8859-1'
-adobe-helvetica-medium-r-normal--12-120-75-75-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1
deb# xlsfonts -fn '-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*'
-adobe-courier-medium-r-normal--12-120-75-75-m-0-iso8859-1
-adobe-courier-medium-r-normal--12-120-75-75-m-0-iso8859-1
-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
-adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1

Finally the solution (or at least workaround, since I initially thought it should not be necessary) was to download the additional fonts for nxclient (windows side) from NoMachine site. It helped in my case, although I don't fully understand why it was necessary, see the note from the NoMachine site:

NOTE: The additional fonts are only needed when running very old Unix applications, requiring the use of client-side fonts. All recent Unix applications use fonts stored on the server, that are fully supported by NX.

Microsoft TrueType fonts
With default settings some websites (like Reddit) render in fonts without antialiasing. The page with such fonts looks like follows:
In font mapper settings you can probably do many things about it, but I am not expert in this area. What worked for me was to install the fonts I am used to - the msttcorefonts package.
In order to be able to install the fonts, you have to extend your sources.list to provide access to non-free packages. For detailed explanation see this post.
After the successful installation the same site looks as follows:

WMU-6500FS - dropbear-0.52

2008-12-22T20:28:00.004+01:00

Introduction

It seems to me that dropbear ssh daemon from JoKeR's package is configured so it does not support public key authentication. It is possible that I am doing something wrong but I was trying hard to make it work and did not succeed.
Finally I decided to build dropbear on my own, since the publickey authentication feature is essential for me (I am using the box for hosting of git repositories and I really do not want to type my password every time I commit a code).

Build result

[binary] [file list]

Installation

box# cd /mnt/C
box# ./filopack.sh --download dropbear-0.52
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package dropbear-0.52 from http://filodej.ic.cz ...
connected!

Length: 502 [text/plain]
connected!

Length: 177,869 [application/x-tar]
box# ./filopack.sh --install dropbear-0.52
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack dropbear-0.52 locally at /mnt/C (y/n)?y
sys/bin/dbclient
sys/bin/dropbearmulti
sys/bin/dropbearkey
sys/bin/dropbearconvert
sys/bin/scp
sys/sbin/dropbear
box# killall dropbear
box# dropbear

In this post I am going to describe how I built the dropbear package and diagnosed and solved (or worked around) problems which arose during the whole process.

JoKeR's dropbear

Let's try co connect to the box:
If ssh daemon (dropbear in our case) is not running on the box, the error message will likely look as follows:

deb# ssh root@storage
ssh: connect to host storage port 22: Connection refused

If everything is ok, it should look similar to following:

deb# ssh root@storage
root@storage's password: < type a password > 

  [    FW 4.00b4.C009-M[NG]    ]
  [ http://mgb111.pradnik.net/ ]

box#

Now we are trying to get rid of typing the password. We use the RSA public authentication for it.

Publickey authentication

If we do not have a RSA key generated yet, we can generate it as follows:

deb# cd ~
deb# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/filodej/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/filodej/.ssh/id_rsa.
Your public key has been saved in /home/filodej/.ssh/id_rsa.pub.
The key fingerprint is:
89:...:b4... filodej@debian

Deploy the public key to the box:

deb# scp .ssh/id_rsa.pub root@storage:/mnt/C/sys/root/.ssh/
root@storage's password:
id_rsa.pub                                                              100%  393     0.4KB/s   00:00

Now, on the box, append the public key to the list of authorized keys:

box# cd /mnt/C/sys/root/.ssh/
box# cat id_rsa.pub >> authorized_keys

From now on, the ssh client should not ask for anything (more precisely, it should not ask for password, it should ask for publickey passphrase if we did not leave it empty - for someone it can look similar as password, but it is completely different thing).

Let's try:

deb# ssh root@storage
root@storage's password:

Simple diagnostics

Ooops, it seems we did not succeed. Let's do some diagnostics (we can use either of "-v", "-vv", "-vvv" verbose modes, one "v" is sufficiend here):

dev# ssh -v root@storage
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to storage [192.168.1.104] port 22.
debug1: Connection established.
debug1: identity file /home/filodej/.ssh/identity type -1
debug1: identity file /home/filodej/.ssh/id_rsa type 1
debug1: identity file /home/filodej/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.50
debug1: no match: dropbear_0.50
...
debug1: Host 'storage' is known and matches the RSA host key.
debug1: Found key in /home/filodej/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: Next authentication method: password
root@storage's password:

Let's try to connect to another machine and compare the trace:

deb# ssh -v root@notasw
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to notasw [192.168.1.103] port 22.
debug1: Connection established.
debug1: identity file /home/filodej/.ssh/identity type -1
debug1: identity file /home/filodej/.ssh/id_rsa type 1
debug1: identity file /home/filodej/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
...
debug1: Host 'notasw' is known and matches the RSA host key.
debug1: Found key in /home/filodej/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/filodej/.ssh/identity
debug1: Offering public key: /home/filodej/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/filodej/.ssh/id_dsa
debug1: Next authentication method: password
root@notasw's password:

We can diff the logs to easily see the differences:

deb# ssh -v root@storage 2> storage.txt
root@storage's password:
<Ctrl-D>
deb# ssh -v root@notasw 2> notas.txt
root@notasw's password:
<Ctrl-D>
deb# diff storage.txt notas.txt
4c4
< debug1: Connecting to storage [192.168.1.104] port 22.
---
> debug1: Connecting to notasw [192.168.1.103] port 22.
9,10c9,10
< debug1: Remote protocol version 2.0, remote software version dropbear_0.50
< debug1: no match: dropbear_0.50
---
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
> debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
23,26c23,28
...
< debug1: Host 'storage' is known and matches the RSA host key.
< debug1: Found key in /home/filodej/.ssh/known_hosts:4
---
...
> debug1: Host 'notasw' is known and matches the RSA host key.
> debug1: Found key in /home/filodej/.ssh/known_hosts:8
33c35,40
< debug1: Authentications that can continue: password
---
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/filodej/.ssh/identity
> debug1: Offering public key: /home/filodej/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/filodej/.ssh/id_dsa

It seems that the JoKeR's daemon is not configured for publickey authentication at all. Ok, let's build our own.

Build process

First we have to download, extract and configure the build:

dev# cd /usr/local/src/
dev# wget http://matt.ucc.asn.au/dropbear/dropbear-0.52.tar.

bz2
dev# tar xjvf dropbear-0.52.tar.bz2 
dev# cd dropbear-0.52
dev# ./configure --prefix /mnt/C/sys
...
configure: Now edit options.h to choose features.

As the message suggests, now we can set up some additional build options:

dev# nano options.h

change:
  #define RSA_PRIV_FILENAME "/etc/dropbear/dropbear_rsa_host_key"
to:
  #define RSA_PRIV_FILENAME "/mnt/C/sys/etc/dropbear_rsa_host_key"

and possibly comment out:
  #define DROPBEAR_DSS
or change:
  #define DSS_PRIV_FILENAME "/etc/dropbear/dropbear_dss_host_key"
to:
  #define DSS_PRIV_FILENAME "/mnt/C/sys/etc/dropbear_dss_host_key"

leave following unchanged:
  #define ENABLE_SVR_PASSWORD_AUTH
  /* PAM requires ./configure --enable-pam */
  /*#define ENABLE_SVR_PAM_AUTH*/
  #define ENABLE_SVR_PUBKEY_AUTH

  /* Wether to ake public key options in authorized_keys file into account */
  #ifdef ENABLE_SVR_PUBKEY_AUTH
  #define ENABLE_SVR_PUBKEY_OPTIONS
  #endif

  #define ENABLE_CLI_PASSWORD_AUTH
  #define ENABLE_CLI_PUBKEY_AUTH
  #define ENABLE_CLI_INTERACT_AUTH

... and make:

dev# make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
...

It compiled successfully, but I have realized that I prefer to link the dependencies statically:

dev# make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" clean
dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
...
/mnt/C/sys/lib/gcc/i386-linux-uclibc/4.1.2/../../../../i386-linux-uclibc/bin/ld: cannot find -lz
collect2: ld returned 1 exit status

... the error means that linker is unable to find a static version of zlib library.
When we investigate that we see taht there is just a dynamic version of the library on the system:

dev# ls /lib/libz*
/lib/libz.so.1  /lib/libz.so.1.2.2
dev# ls /mnt/C/sys/lib/libz*
/mnt/C/sys/lib/libz*: No such file or directory

We could pick the sources and build a static version of zlib library, but for now I decided to re-configure the dropbear build and disable the zlib support:

dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" clean
dev# ./configure --prefix /mnt/C/sys --disable-zlib STATIC=1 
dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"

... now it compiled without problems, we can try to install it and upload to the box:

dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install
...
dev# scp /mnt/C/sys/sbin/dropbear root@storage:/tmp/

Now we can start the brand new version of dropbear daemon on the box:

box# killall dropbear
box# /tmp/dropbear

And try to log in over ssh client (from my debian system):

deb# ssh -vvv root@storage -i ~/.ssh/id_rsa.pub
...
debug2: key: /home/filodej/.ssh/id_rsa.pub (0xb7f7b480)
debug2: key:  (0xb7f7c8e0)
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/filodej/.ssh/identity
debug1: Offering public key: /home/filodej/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/filodej/.ssh/id_dsa
debug1: Next authentication method: password
root@storage's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@storage's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@storage's password:

It seems we have done some progress here, but still are not able to authenticate via publickey. And even if we are using the correct password, permission is denied.

List of valid shells

Let's restart the daemon, but now not forking to the background and logging to the stderr rather that syslog:

box# dropbear -E -F
[4456] Nov 30 23:59:30 Not backgrounding
[4462] Nov 30 23:59:56 Child connection from 192.168.1.103:49013
[4462] Dec 01 00:00:08 user 'root' has invalid shell, rejected

Ok, there is something wrong with the shell settings, let's investigate that:

box# cat /var/config/passwd
root: ... :0:0:root:/mnt/C/sys/root:/mnt/C/sys/bin/bash
...
box# ls /mnt/C/sys/bin/bash
/mnt/C/sys/bin/bash

User root has /mnt/C/sys/bin/bash in his settings, the file exists and is at correct place. Let's look at the list of valid shells:

box# cat /etc/shells
/bin/sh
/sbin/nologin
/bin/nologin
/bin/ash
/sbin/ash
/bin/false
/sbin/false
/mnt/C/sys/bash
/bin/bash
/usr/bin/bash

The path /mnt/C/sys/bash is wrong since the bash executable is in /mnt/C/sys/bin directory, but the /usr/bin/bash path should be ok, since the /usr/bin is just a symlink to /mnt/C/sys/bin:

box# ls -l /usr/bin
lrwxrwxrwx    1 root     root           14 May 21  2008 /usr/bin -> /mnt/C/sys/bin

We have to look at the problem in more detail. Since there is no verbose mode available in dropbear by default, we can enable it in code (I got the inspiration from this post):

dev# nano debug.h
    uncomment:
        #define DEBUG_TRACE

Now when we rebuilt and re-deployed the dropbear, we can run in in verbose mode:

box# dropbear -v -E -F 
...
TRACE (4848): shell is /mnt/C/sys/bin/bash
TRACE (4848): test shell is '/bin/sh'
TRACE (4848): test shell is '/sbin/nologin'
TRACE (4848): test shell is '/bin/nologin'
TRACE (4848): test shell is '/bin/ash'
TRACE (4848): test shell is '/sbin/ash'
TRACE (4848): test shell is '/bin/false'
TRACE (4848): test shell is '/sbin/false'
TRACE (4848): test shell is '/mnt/C/sys/bash'
TRACE (4848): test shell is '/bin/bash'
TRACE (4848): test shell is '/usr/bin/bash'

As can be seen in the svr-auth.c source code:

00273       while ((listshell = getusershell()) != NULL) {
00274             TRACE(("test shell is '%s'", listshell))
00275             if (strcmp(listshell, usershell) == 0) {
00276                   /* have a match */
00277                   goto goodshell;
00278             }
00279       }

... the shell path is compared as plain strings and so /usr/bin/bash and /mnt/C/sys/bin/bash are two different things.

Since the /etc/shells file is placed on read-only file system we have to make a change in /var/config/passwd file:

box# sed -i 's|/mnt/C/sys/bin/|/usr/bin/|g' /var/config/passwd

Since it is overwritten on every boot, we have to make the correction in our rc.cfg file, to make it permanent:

nano /mnt/C/sys/etc/rc.d/rc.cfg
   add the following line:
    sed -i 's|/mnt/C/sys/bin/|/usr/bin/|g' /var/config/passwd

Now when we try to connect again, we can see that the problem is solved:

[394] Dec 01 01:32:25 pubkey auth succeeded for 'root' with key md5 

3a:...:05 from 192.168.1.103:44521

Read only file system

There is another problem:

[394] Dec 01 01:32:25 chown(/dev/ttyp2, 0, 0) failed: Read-only file system
[394] Dec 01 01:32:26 exit after auth (root): chmod(/dev/ttyp2, 0622) failed: Read-only file system

The problem seems to be in the file sshpty.c in function pty_setowner but I am not sure what exactly is wrong. We can try to debug it remotely in order to find out what is going on. One option in debug.h can be handy - we can disable the forking the sub-processes - then there is just one dropbear process to attach.

/* To debug with GDB it is easier to run with no forking of child processes.
   You will need to pass "-F" as well. */
/* #define DEBUG_NOFORK */

Let's rebuild it with debug info:

dev# nano Makefile
...
CFLAGS=-I. -I$(srcdir) -I$(srcdir)/libtomcrypt/src/headers/ $(CPPFLAGS) -I/mnt/C/sys/include 

-I/mnt/C/sys/X11/include -g
...

Rebuild and redeploy the dropbear binary.

Now we can run the dropbear process on the box:

box# dropbear -E -F
box# [4498] Dec 21 23:50:01 Running in background
...

On another console connected to the box we start the gdbserver:

box# gdbserver colinux:2345 --attach 4498
Attached; pid = 4498
Listening on port 2345
...

Now on the mirror system we can start the gdb:

dev# gdb dropbear
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux-uclibc"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) target remote 192.168.1.104:2345
Remote debugging using 192.168.1.104:2345
0x0806d7ad in fast_s_mp_sqr (a=0xbfffe348, b=0xbfffe348) at bn_fast_s_mp_sqr.c:73
73               _W += ((mp_word)*tmpx++)*((mp_word)*tmpy--);
(gdb) break pty_setowner
Breakpoint 1 at 0x805bfcc: file sshpty.c, line 364.
(gdb) cont
Continuing.

Now we are ready to connect over ssh:

dev# ssh root@storage
root@storage's password:

... and debugger stops on the breakpoint:

Breakpoint 1, pty_setowner (pw=0x80dd480, tty_name=0x80e1578 "/dev/ttyp3") at sshpty.c:364
364             grp = getgrnam("tty");
(gdb) step
365             if (grp) {
(gdb) step
369                     gid = pw->pw_gid;
(gdb) step
370                     mode = S_IRUSR | S_IWUSR | S_IWGRP | S_IWOTH;
(gdb) step
378             if (stat(tty_name, &st)) {
(gdb) step
382             dropbear_log(LOG_ERR, "stat: %u", (unsigned int)st.st_uid );
(gdb) print st
$1 = {st_dev = 7936, __pad1 = 45352, __st_ino = 363, st_mode = 8630, st_nlink = 1, st_uid = 0, st_gid = 5,
  st_rdev = 771, __pad2 = 0, st_size = 0, st_blksize = 4096, st_blocks = 0, st_atime = 1206970720,
  st_atimensec = 134760895, st_mtime = 1206970720, st_mtimensec = 134691188, st_ctime = 1206970720,
  st_ctimensec = 135124096, st_ino = 363}
(gdb) print tty_name
$2 = 0x80e1578 "/dev/ttyp3"
(gdb) next
383             if (st.st_uid != pw->pw_uid || st.st_gid != gid) {
(gdb) print *pw
$3 = {pw_name = 0x80dd380 "root", pw_passwd = 0x80dd385 "...", pw_uid = 0, pw_gid = 0, pw_gecos = 

0x80dd3a4 "root", pw_dir = 0x80dd3a9 "/mnt/C/sys/root", pw_shell = 0x80dd3b9 "/usr/bin/bash"}
...
(gdb) step
401 if ((st.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != mode) {
(gdb) print /o st.st_mode
$4 = 020666
(gdb) step
402                     if (chmod(tty_name, mode) < 0) {
(gdb) step
403                             if (errno == EROFS &&
(gdb) step
409                                     dropbear_exit("chmod(%.100s, 0%o) failed: %.100s",

Ok, we have analyzed the situation. The pty_setowner function is trying to initialize the device file representing the terminal we are trying to connect to. Device file is on read only file system and so the attribute changes do not succeed.

If changing the tty owner does not succeed, the code at (1) activates more relaxed mode in case the file system is read only and tty is owned by root or the uids match. In our case the relaxed mode is activated and the server just writes the warning chown(/dev/ttyp2, 0, 0) failed: Read-only file system and continues.

Then there is code changing tty read mode. This code tries to prevent unauthorized users from reading tty content. In order to get just a warning, the reading by group and reading by others must be prohibited. In our case the st.st_mode is 020666 (read/write by everyone) and so we get the error chmod(/dev/ttyp2, 0622) failed: Read-only file system.

 /*
  * Change owner and mode of the tty as required.
  * Warn but continue if filesystem is read-only and the uids match/
  * tty is owned by root.
  */
 if (stat(tty_name, &st)) {
  dropbear_exit("pty_setowner: stat(%.101s) failed: %.100s",
    tty_name, strerror(errno));
 }

 if (st.st_uid != pw->pw_uid || st.st_gid != gid) {
  if (chown(tty_name, pw->pw_uid, gid) < 0) {
   if (errno == EROFS &&
       (st.st_uid == pw->pw_uid || st.st_uid == 0)) {
(1)    dropbear_log(LOG_ERR,
     "chown(%.100s, %u, %u) failed: %.100s",
      tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid,
      strerror(errno));
   } else {
    dropbear_exit("chown(%.100s, %u, %u) failed: %.100s",
        tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid,
        strerror(errno));
   }
  }
 }

 if ((st.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != mode) {

  if (chmod(tty_name, mode) < 0) {
   if (errno == EROFS &&
(2)       (st.st_mode & (S_IRGRP | S_IROTH)) == 0) {
    dropbear_log(LOG_ERR,
     "chmod(%.100s, 0%o) failed: %.100s",
     tty_name, mode, strerror(errno));
   } else {
    dropbear_exit("chmod(%.100s, 0%o) failed: %.100s",
        tty_name, mode, strerror(errno));
   }
  }
 }

Some discussions (for example here and here) recommended to configure build in order to disable openpty:

dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" clean
dev# ./configure --prefix /mnt/C/sys --disable-zlib --disable-openpty STATIC=1 
dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install

But it did not help in this case.

Nowadays I do not know a better workaround in order to make it work than change the dropbear_exit to dropbear_log. I have found a discussion about this on Web and the following rationale seems reasonable:

Ah. If it's a single user system, the easiest solution might just be to disable the chown() and chmod() call - it's not like there're any other users who might be sniffing :)
(sshpty.c is where you'll find those chown/chmods).

... but be careful, you were warned ;-)

Minor issues

There were also two another problems (just warnings). The first was wtmp problem:

[2398] Dec 01 12:13:04 wtmp_write: problem writing /var/log/wtmp: No such file or directory

It was solved by adding the --disable-wtmp to the configure command line.

The second was logging problem:

dev# ssh root@storage
root@storage's password:
[2719] Dec 01 13:25:53 lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
[2719] Dec 01 13:25:53 lastlog_openseek: /var/log/lastlog is not a file or directory!

  [    FW 4.00b4.C009-M[NG]    ]
  [ http://mgb111.pradnik.net/ ]

We are not alone on this (see this post or OpenWrt ticket, also this archive served as a source of information).

It was solved by adding the --disable-lastlog to the configure command line.

Final build

As a result we have the following configure command line:

dev# ./configure --prefix /mnt/C/sys --disable-zlib --disable-openpty --disable-wtmp --disable-lastlog

Now we can modify the Makefile in order to generate code optimized for size:

dev# nano Makefile
...
CFLAGS=-I. -I$(srcdir) -I$(srcdir)/libtomcrypt/src/headers/ $(CPPFLAGS) -I/mnt/C/sys/include -I/mnt/C/sys/X11/include -Os

If we want to create multi-application instead of individual applications, we can use MULTI variable on the make command line:

dev# make STATIC=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" clean
dev# make STATIC=1 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"

We can strip the sources to spare some space:

dev# make STATIC=1 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" strip

And are ready to install and create the package:

dev# make STATIC=1 MULTI=1 PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install
dev# cd /mnt/C
dev# ./filopack.sh --pack dropbear-0.52

Test

Start the dropbear server (logging to strerr, not forking to background):

box# dropbear -E -F
[902] Dec 22 02:14:49 Not backgrounding

This is output when I was connecting from a machine without a registered public key:

[906] Dec 22 02:14:52 Child connection from 192.168.1.102:44241
[906] Dec 22 02:15:02 password auth succeeded for 'root' from 192.168.1.102:44241
[906] Dec 22 02:15:02 chown(/dev/ttyp3, 0, 0) failed: Read-only file system
[906] Dec 22 02:15:02 !!! Filodej is warning you. Be sure you are the only user !!!
[906] Dec 22 02:15:02 chmod(/dev/ttyp3, 0622) failed: Read-only file system
[906] Dec 22 02:15:47 chown /dev/ttyp3 0 0 failed: Read-only file system
[906] Dec 22 02:15:47 chmod /dev/ttyp3 0666 failed: Read-only file system
[906] Dec 22 02:15:47 exit after auth (root): Exited normally

This is output when I was connecting from a machine with registered public key:

[913] Dec 22 02:15:59 Child connection from 192.168.1.102:44242
[913] Dec 22 02:16:06 pubkey auth succeeded for 'root' with key md5 f1:...:3b from 192.168.1.102:44242
[913] Dec 22 02:16:06 chown(/dev/ttyp3, 0, 0) failed: Read-only file system
[913] Dec 22 02:16:06 !!! Filodej is warning you. Be sure you are the only user !!!
[913] Dec 22 02:16:06 chmod(/dev/ttyp3, 0622) failed: Read-only file system
[913] Dec 22 02:16:21 chown /dev/ttyp3 0 0 failed: Read-only file system
[913] Dec 22 02:16:21 chmod /dev/ttyp3 0666 failed: Read-only file system
[913] Dec 22 02:16:21 exit after auth (root): Exited normally

WMU-6500FS - xterm 237

2008-12-20T22:30:00.022+01:00

GUI dependencies: [X.Org]

Build result

[binary] [file list]

Installation

box# cd /mnt/C
box# ./filopack.sh --download xterm-237
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package xterm-237 from http://filodej.ic.cz ...
connected!

Length: 502 [text/plain]
connected!

Length: 177,869 [application/x-tar]
box# ./filopack.sh --install xterm-237
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack xterm-237 locally at /mnt/C (y/n)?y
sys/X11/share/pixmaps/xterm-color_32x32.xpm
sys/X11/share/pixmaps/xterm-color_48x48.xpm
sys/X11/share/pixmaps/xterm_32x32.xpm
sys/X11/share/pixmaps/xterm_48x48.xpm
sys/X11/man/man1/xterm.1
sys/X11/man/man1/resize.1
sys/X11/man/man1/uxterm.1
sys/X11/man/man1/koi8rxterm.1
sys/X11/lib/X11/app-defaults/XTerm
sys/X11/lib/X11/app-defaults/XTerm-color
sys/X11/lib/X11/app-defaults/UXTerm
sys/X11/lib/X11/app-defaults/KOI8RXTerm
sys/X11/bin/xterm
sys/X11/bin/resize
sys/X11/bin/uxterm
sys/X11/bin/koi8rxterm
box# xterm

Make sure you have the environment variables set properly (you can make it permanent e.g. by editing the /mnt/C/sys/etc/profile; for details see the X Configuration post):

PATH variable can possibly contain the /mnt/C/sys/X11/bin/ path:

box# export PATH=$PATH:/mnt/C/sys/X11/bin/

LD_LIBRARY_PATH must (among others) contain the /mnt/C/sys/X11/lib path:

box# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/C/sys/X11/lib/

DISPLAY environment variable properly set to a display of a machine running xserver:

box# export DISPLAY=<machine>:<display-number>

... or in case you are using putty, X11 forwarding enabled:

Build procedure

First we have to initialize the package timestamp.

dev# cd /mnt/C
dev# ./filopack.sh --init xterm-237 
Configuration file .filopack/.config file found and used
Timestamp written to file .filopack/xterm-237.ts

Now we can download and extract the source.

dev# cd /usr/local/src
dev# wget ftp://invisible-island.net/xterm/xterm-237.tgz
...
Length: 860,424 (unauthoritative)

100%[==========================================================>] 860,424       14.59K/s    ETA 00:00

14:18:14 (17.14 KB/s) - `xterm-237.tgz' saved [860424]

dev# tar xzvf xterm-237.tgz 
...
dev# cd xterm-237

We configure the build in order to have access to XOrg header files and libraries:

dev#  ./configure --x-includes=/mnt/C/sys/X11/include/ --x-libraries=/mnt/C/sys/X11/lib/ --prefix=/mnt/C/sys/X11
...

... and make and install the source:

dev# make
...
dev# make install
...

We can test the installation:

dev# /mnt/C/sys/X11/bin/xterm
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
/mnt/C/sys/X11/bin/xterm Xt error: Can't open display: %s
/mnt/C/sys/X11/bin/xterm:  DISPLAY is not set

Oops, I forgot to set the display variable on the mirror machine. Let's do it now (note that the IP address 192.168.2.1 is specific to my network configuration):

dev# export DISPLAY=192.168.2.1:0
dev# /mnt/C/sys/X11/bin/xterm
xterm: Error 18, errno 2: No such file or directory
Reason: spawn: open() failed on ptsname

It seems there is still some error. Let's investigate it with strace:

dev# strace -f /mnt/C/sys/X11/bin/xterm 2> strace.txt

<Ctrl-C>

dev# tail -n 120 strace.txt
[pid  8119] close(8 <unfinished ...>
[pid  8120] <... setsid resumed> )      = 8120
[pid  8119] <... close resumed> )       = 0
[pid  8120] setpgid(0, 0 <unfinished ...>
[pid  8119] close(5 <unfinished ...>
[pid  8120] <... setpgid resumed> )     = -1 EPERM (Operation not permitted)
[pid  8119] <... close resumed> )       = 0
[pid  8120] ioctl(4, TIOCSPTLCK <unfinished ...>
[pid  8119] read(7,  <unfinished ...>
[pid  8120] <... ioctl resumed> , [0])  = 0
[pid  8120] ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid  8120] ioctl(4, TIOCGPTN, [2])     = 0
[pid  8120] open("/dev/pts/2", O_RDWR)  = -1 ENOENT (No such file or directory)
[pid  8120] write(2, "xterm", 5xterm)        = 5
[pid  8120] write(2, ": Error ", 8: Error )     = 8
[pid  8120] write(2, "18", 218)           = 2
[pid  8120] write(2, ", errno ", 8, errno )     = 8
[pid  8120] write(2, "2", 12)            = 1
[pid  8120] write(2, ": ", 2: )           = 2
[pid  8120] write(2, "No such file or directory", 25No such file or directory) = 25
[pid  8120] write(2, "\n", 1
)           = 1
[pid  8120] write(2, "Reason: ", 8Reason: )     = 8
[pid  8120] write(2, "spawn: open() failed on ptsname", 31spawn: open() failed on ptsname) = 31
[pid  8120] write(2, "\n", 1
)           = 1
[pid  8120] ioctl(4, TCFLSH, 0x1)       = 0
[pid  8120] chown("/dev/pts/2", 0, 0)   = -1 ENOENT (No such file or directory)
[pid  8120] chmod("/dev/pts/2", 0666)   = -1 ENOENT (No such file or directory)
[pid  8120] close(4)                    = 0
[pid  8120] munmap(0xb7c10000, 33608)   = 0
[pid  8120] munmap(0xb7c0b000, 17560)   = 0
[pid  8120] _exit(18)                   = ?
Process 8120 detached
<... read resumed> "", 1048)            = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
...

xterm is unable to open the pseudo terminal device, it should be OK when deployed to the box (there is no full device mapping on my mirror system; it is just chroot-ed to some sub-directory of hosting system).

Let's create the package:

dev# ./filopack.sh --pack xterm-237
Configuration file .filopack/.config file found and used
-rw-r--r-- root/root      1381 2008-12-20 14:27:33 sys/X11/share/pixmaps/xterm-color_32x32.xpm
-rw-r--r-- root/root      2710 2008-12-20 14:27:33 sys/X11/share/pixmaps/xterm-color_48x48.xpm
-rw-r--r-- root/root      2110 2008-12-20 14:27:33 sys/X11/share/pixmaps/xterm_32x32.xpm
-rw-r--r-- root/root      2586 2008-12-20 14:27:33 sys/X11/share/pixmaps/xterm_48x48.xpm
-rw-r--r-- root/root    174641 2008-12-20 14:27:32 sys/X11/man/man1/xterm.1
-rw-r--r-- root/root      2678 2008-12-20 14:27:33 sys/X11/man/man1/resize.1
-rw-r--r-- root/root      2967 2008-12-20 14:27:33 sys/X11/man/man1/uxterm.1
-rw-r--r-- root/root      3188 2008-12-20 14:27:33 sys/X11/man/man1/koi8rxterm.1
-rw-r--r-- root/root      6853 2008-12-20 14:27:33 sys/X11/lib/X11/app-defaults/XTerm
-rw-r--r-- root/root      4324 2008-12-20 14:27:33 sys/X11/lib/X11/app-defaults/XTerm-color
-rw-r--r-- root/root      2109 2008-12-20 14:27:33 sys/X11/lib/X11/app-defaults/UXTerm
-rw-r--r-- root/root       747 2008-12-20 14:27:33 sys/X11/lib/X11/app-defaults/KOI8RXTerm
-rwxr-xr-x root/root    334759 2008-12-20 14:27:32 sys/X11/bin/xterm
-rwxr-xr-x root/root     11157 2008-12-20 14:27:32 sys/X11/bin/resize
-rwxr-xr-x root/root      2088 2008-12-20 14:27:32 sys/X11/bin/uxterm
-rwxr-xr-x root/root      2163 2008-12-20 14:27:32 sys/X11/bin/koi8rxterm

... and deploy the package to the box:

dev# ./filopack.sh --upload xterm-237
Configuration file .filopack/.config file found and used
Sure to upload xterm-237 to root@storage:/mnt/C (y/n)?y
root@storage's password:
root@storage's password:

Now on the box, we can install it:

box# [root@storage C]# ./filopack.sh --install xterm-237
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Module xterm-237 not found in package list - use 'tar.bz2' extension
Sure to unpack xterm-237 locally at /mnt/C (y/n)?y
sys/X11/share/pixmaps/xterm-color_32x32.xpm
sys/X11/share/pixmaps/xterm-color_48x48.xpm
sys/X11/share/pixmaps/xterm_32x32.xpm
sys/X11/share/pixmaps/xterm_48x48.xpm
sys/X11/man/man1/xterm.1
sys/X11/man/man1/resize.1
sys/X11/man/man1/uxterm.1
sys/X11/man/man1/koi8rxterm.1
sys/X11/lib/X11/app-defaults/XTerm
sys/X11/lib/X11/app-defaults/XTerm-color
sys/X11/lib/X11/app-defaults/UXTerm
sys/X11/lib/X11/app-defaults/KOI8RXTerm
sys/X11/bin/xterm
sys/X11/bin/resize
sys/X11/bin/uxterm
sys/X11/bin/koi8rxterm

And test the installation:

box# xterm
Cannot chown /dev/ttyp4 to 0,0: Read-only file system
Cannot chmod /dev/ttyp4 to 620 currently 666: Read-only file system
Cannot chown /dev/ttyp4 to 0,0: Read-only file system

The problem here is that xterm is trying to change the rights for the terminal device it is using (/dev/ttyp4 in this case) in order to prevent a read access of an unauthorized person (octal value 620 means that only root can read and write the terminal and users from the same group can just write). However, since the file system is read-only the chmod operation does not succeed and so the terminal device stays readable for everyone.
I was dealing with the same issue during the dropbear build.

Anyway, in case you are using the box on a trusted network with no one "sniffing around" and have it properly secured from the outside world then the warning should not mean any harm. Maybe it could be solved by a change in configuration (or by a slight change in source code), but I am not going to solve it now.

WMU-6500FS - built sw -Python 2.5.2

2008-12-08T17:59:00.007+01:00

[Homepage]

[files] [binary]

First I briefly write about the initial build:

dev# cd /usr/local/src
dev# wget http://python.org/ftp/python/2.5.2/Python-2.5.2.tgz
dev# tar xvzf Python-2.5.2.tgz
dev# cd Python-2.5.2
dev# ./configure --prefix=/mnt/C/sys --enable-shared
dev# make

There was an error with missing 'yperr_string' symbol (I am not sure whether it was during the build or when I launched python console). The symbol was needed by the nis extension module. I do not know how on earth I would utilize an Interface to Sun's NIS (Yellow pages) so as a workaround I simply disabled it.

dev# make
dev# make install
dev# python

Another failure - error while loading shared libraries: libpython2.5.so.1.0 (it is located in /mnt/C/sys/lib).
As a solution, if there was a dynamic loader configuration on the box (/etc/ld.so.conf.d) we could do following:

dev# echo /usr/local/lib > /etc/ld.so.conf.d/python2.5.conf
dev# ldconfig

As there is not, we can use the LD_LIBRARY_PATH variable instead:

dev# nano /mnt/C/sys/etc/rc-local
Add following:
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/C/sys/lib

Now everything works ok.

After some time I realized that there is a readline extension module missing on the system. This module is needed for interactive console applications, and particularly is needed for the deluge console:

box# deluge --ui=null
[INFO    ] 21:58:04 main:93 Deluge ui 1.0.5
[DEBUG   ] 21:58:04 main:94 options: {'config': None, 'logfile': None, 'ui': 'null'}
[DEBUG   ] 21:58:04 main:95 args: []
[DEBUG   ] 21:58:05 configmanager:44 ConfigManager started..
[INFO    ] 21:58:05 main:98 Starting ui..
[DEBUG   ] 21:58:05 ui:44 UI init..
[DEBUG   ] 21:58:05 configmanager:88 Getting config 'ui.conf'
[DEBUG   ] 21:58:05 config:47 Config created with filename: ui.conf
[DEBUG   ] 21:58:05 config:48 Config defaults: {'default_ui': 'gtk'}
[INFO    ] 21:58:05 ui:68 Starting NullUI..
[DEBUG   ] 21:58:06 client:54 CoreProxy init..
Traceback (most recent call last):
  File "/usr/bin/deluge", line 8, in <module>
    load_entry_point('deluge==1.0.5', 'console_scripts', 'deluge')()
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/main.py", line 99, in start_ui
    UI(options, args)
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/ui/ui.py", line 69, in __init__
    from deluge.ui.null.deluge_shell import NullUI
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/ui/null/deluge_shell.py", line 29, in <module>
    import readline
ImportError: No module named readline

We can replicate this problem directly from the python console:

dev# python
Python 2.5.2 (r252:60911, May  3 2008, 16:19:27)
[GCC 3.3.6] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named readline
>>>

So let's look at the old log of python's configure script to see why the readline extension package was not built:

dev# cat config.log | grep readline
configure:20980: checking for readline in -lreadline
configure:21015: gcc -pthread -o conftest -g -O2   conftest.c -lreadline  -lpthread -ldl  -lutil >&5
/usr/bin/ld: cannot find -lreadline
| char readline ();
| return readline ();
configure:21126: checking for rl_callback_handler_install in -lreadline
configure:21161: gcc -pthread -o conftest -g -O2   conftest.c -lreadline  -lpthread -ldl  -lutil >&5
/usr/bin/ld: cannot find -lreadline
configure:21254: checking for rl_pre_input_hook in -lreadline
configure:21289: gcc -pthread -o conftest -g -O2   conftest.c -lreadline  -lpthread -ldl  -lutil >&5
/usr/bin/ld: cannot find -lreadline
configure:21325: checking for rl_completion_matches in -lreadline
configure:21360: gcc -pthread -o conftest -g -O2   conftest.c -lreadline  -lpthread -ldl  -lutil >&5
/usr/bin/ld: cannot find -lreadline
ac_cv_lib_readline_readline=no
ac_cv_lib_readline_rl_callback_handler_install=no
ac_cv_lib_readline_rl_completion_matches=no
ac_cv_lib_readline_rl_pre_input_hook=no

We can see that the library simply was not on the system and so the python configure script decided to exclude it's python wrapper from the build.

Before we proceed, we have to build the GNU readline and create a new package for it. How it was done is described in this post.

Now we have the libreadline.so library on the system and so can proceed to re-configure and re-build the python package. First we create a new timestamp file for python package and touch all the old files (in order to be included in the package). We can use the filopack script for that purpose:

dev# cd /mnt/C
dev# ./filopack.sh --init python-2.5.2
dev# ./filopack.sh --touch python-2.5.2
Configuration file .filopack/.config file found and used
Sure to touch all files of the python-2.5.2 locally at /mnt/C (y/n)?y
...

Now we can move to the python source directory and re-configure the build:

dev# cd /usr/local/src/Python-2.5.2
dev# ./configure --prefix=/mnt/C/sys --enable-shared
...

Let's check whether the readline package was found and included to the build:

dev# cat config.log | grep readline
configure:20980: checking for readline in -lreadline
configure:21015: gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lpthread -ldl  -lutil >&5
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetnum'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgoto'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetflag'
/mnt/C/sys/lib/libreadline.so: undefined reference to `BC'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tputs'
/mnt/C/sys/lib/libreadline.so: undefined reference to `PC'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetent'
/mnt/C/sys/lib/libreadline.so: undefined reference to `UP'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetstr'
...
ac_cv_lib_readline_readline=no
ac_cv_lib_readline_rl_callback_handler_install=no
ac_cv_lib_readline_rl_completion_matches=no
ac_cv_lib_readline_rl_pre_input_hook=no

The situation changed, the readline library is (presumably) no longer missing, but still there are some missing symbols and thus the configure test failed.

After a short googling (for query "libreadline.so: undefined reference to BC PC UP") I found this page.
It seems that the missing symbols should be present in ncurses library.

Let's look what symbols are at the library in our system:

dev# nm /lib/libncurses.so | grep "tgetnum\|tgoto\|tgetflag\|BC\|PC\|UP"
0003a544 B BC
0003a770 B PC
0003a540 B UP
000248e1 T tgetflag
00024958 T tgetnum
00024b0c T tgoto

It means that the symbols are there, but the python configuration script did not manage to find the library.

For quick feedback for our experiments we can create a dummy C file and use the same compiler command line as the configure script did:

dev# echo "int main() { return 0; }" > conftest.c
dev# gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lpthread -ldl  -lutil
/mnt/C/sys/lib/gcc/i386-linux-uclibc/4.1.2/../../../../i386-linux-uclibc/lib/crt1.o: In function `_start':
crt1.S:(.text+0x27): undefined reference to `main'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetnum'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgoto'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetflag'
/mnt/C/sys/lib/libreadline.so: undefined reference to `BC'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tputs'
/mnt/C/sys/lib/libreadline.so: undefined reference to `PC'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetent'
/mnt/C/sys/lib/libreadline.so: undefined reference to `UP'
/mnt/C/sys/lib/libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status

We see that the linker ended up with the same error. Now we can try to fix the command line. There is missing ncurses library on the command line; what about adding it explicitly?

dev# gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib
 -L/mnt/C/sys/X11/lib conftest.c -lncurses -lreadline  -lpthread -ldl  -lutil

The test build now works, so now we can remove the temporary C-file and re-configure the python build:

dev# rm conftest.c

dev# LIBS="-lncurses" ./configure --prefix=/mnt/C/sys --enable-shared
...

Let's make sure that readline package passed the configure test:

 
dev# cat config.log | grep readline
configure:20980: checking for readline in -lreadline
configure:21015: gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lpthread -ldl -lncurses -lutil >&5
configure:21126: checking for rl_callback_handler_install in -lreadline
configure:21161: gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lreadline -lpthread -ldl -lncurses -lutil >&5
configure:21254: checking for rl_pre_input_hook in -lreadline
configure:21289: gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lreadline -lpthread -ldl -lncurses -lutil >&5
configure:21325: checking for rl_completion_matches in -lreadline
configure:21360: gcc -pthread -o conftest -I/mnt/C/sys/include -I/mnt/C/sys/X11/include  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib conftest.c -lreadline  -lreadline -lpthread -ldl -lncurses -lutil >&5
ac_cv_lib_readline_readline=yes
ac_cv_lib_readline_rl_callback_handler_install=yes
ac_cv_lib_readline_rl_completion_matches=yes
ac_cv_lib_readline_rl_pre_input_hook=yes

Yes, everything is ok now, we can build the source and install the binaries:

dev# make
...
/mnt/C/sys/include/sqlite3.h: version 3.5.8
INFO: Can't locate Tcl/Tk libs and/or headers
building 'readline' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/readline.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/readline.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/readline.o -L/usr/lib/termcap -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lreadline -lncurses -lpython2.5 -o build/lib.linux-i686-2.5/readline.so
building 'nis' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/nismodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lnsl -lpython2.5 -o build/lib.linux-i686-2.5/nis.so
*** WARNING: renaming "nis" since importing it failed: dynamic module does not define init function (initnis)
running build_scripts

dev# make install
...

Now, let's test the new installation:

dev# python
Python 2.5.2 (r252:60911, Dec  8 2008, 07:26:01)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline

This is fine; and what about the deluge console:

dev# deluge --ui=null
[INFO    ] 07:28:18 main:93 Deluge ui 1.0.5
[DEBUG   ] 07:28:18 main:94 options: {'config': None, 'logfile': None, 'ui': 'null'}
[DEBUG   ] 07:28:18 main:95 args: []
[DEBUG   ] 07:28:18 configmanager:44 ConfigManager started..
[INFO    ] 07:28:18 main:98 Starting ui..
[DEBUG   ] 07:28:18 ui:44 UI init..
[DEBUG   ] 07:28:18 configmanager:88 Getting config 'ui.conf'
[DEBUG   ] 07:28:18 config:47 Config created with filename: ui.conf
[DEBUG   ] 07:28:18 config:48 Config defaults: {'default_ui': 'gtk'}
[INFO    ] 07:28:18 ui:68 Starting NullUI..
[DEBUG   ] 07:28:18 client:54 CoreProxy init..
Welcome to deluge-shell. Type 'help' to see a list of available commands.
> help

Available commands:
        * add: Add a torrent
        * config-set: Change a configuration setting
        * configs: Show configuration values
        * connect: Connect to a new deluge server.
        * del: Remove a torrent
        * exit: Exit from the client.
        * halt: Shutdown the deluge server.
        * help: Show help
        * info: Show information about the torrents
        * pause: Pause a torrent
        * quit: Exit from the client.
        * resume: Resume a torrent
        * rm: Remove a torrent
> quit

Thanks

Everything is now ok, we can create a new python package:

dev# cd /mnt/C
dev# ./filopack.sh --pack python-2.5.2
...

I realized that there are many files which are not a necessary part of the resulting package. Thhose are files with .pyc and .pyo extensions - just in time compiled python files. So I removed them from the list and re-created the package:

dev# ./filopack.sh -R --pack python-2.5.2
...

I have uploaded the resulting package on the web site. Now we can fix the problem on the box.

First let's look at the summary of installed files:

box# cd /mnt/C
box# ./filopack.sh --summary
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)

Filodej package summary:
Package name                          downloaded [#installed/#total]
--------------------------------------------------------------------
...
python-2.5.2                              no           [3525/3648]
...

... so the python package is installed; let's remove it:

box# ./filopack.sh --remove python-2.5.2
Configuration file .filopack/.config file found and used
Sure to remove python-2.5.2 locally at /mnt/C (y/n)?y
...

Now we can download and install both readline-5.2:

box# ./filopack.sh --download readline-5.2
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package readline-5.2 from http://filodej.ic.cz ...
connected!

Length: 573 [text/plain]
connected!

Length: 265,962 [application/x-tar]

box# ./filopack.sh --install readline-5.2
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack readline-5.2 locally at /mnt/C (y/n)?y
sys/lib/libreadline.a
sys/lib/libhistory.a
sys/lib/libhistory.so.5
sys/lib/libhistory.so.5.2
sys/lib/libhistory.so
sys/lib/libreadline.so.5.2
sys/lib/libreadline.so.5
sys/lib/libreadline.so
sys/man/man3/readline.3
sys/man/man3/history.3
sys/include/readline/rltypedefs.h
sys/include/readline/chardefs.h
sys/include/readline/history.h
sys/include/readline/keymaps.h
sys/include/readline/readline.h
sys/include/readline/rlconf.h
sys/include/readline/rlstdc.h
sys/include/readline/tilde.h
sys/info/readline.info
sys/info/rluserman.info
sys/info/history.info

... and python-2.5.2 package:

box# ./filopack.sh --download python-2.5.2
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package python-2.5.2 from http://filodej.ic.cz ...
connected!

Length: 134,205 [text/plain]
connected!

Length: 12,984,464 [application/x-tar]

box# ./filopack.sh --install python-2.5.2
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack python-2.5.2 locally at /mnt/C (y/n)?y
...

After the installation everything seemed ok:

box# python
Python 2.5.2 (r252:60911, Dec  8 2008, 07:26:01)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>>

... but surprisingly one more problem arose when I ran the deluge console:

box# deluged.sh

box# deluge --ui=null
[INFO    ] 16:56:44 main:93 Deluge ui 1.0.5
[DEBUG   ] 16:56:44 main:94 options: {'config': None, 'logfile': None, 'ui': 'null'}
[DEBUG   ] 16:56:44 main:95 args: []
[DEBUG   ] 16:56:45 configmanager:44 ConfigManager started..
[INFO    ] 16:56:45 main:98 Starting ui..
[DEBUG   ] 16:56:45 ui:44 UI init..
[DEBUG   ] 16:56:45 configmanager:88 Getting config 'ui.conf'
[DEBUG   ] 16:56:45 config:47 Config created with filename: ui.conf
[DEBUG   ] 16:56:45 config:48 Config defaults: {'default_ui': 'gtk'}
[INFO    ] 16:56:45 ui:68 Starting NullUI..
[DEBUG   ] 16:56:46 client:54 CoreProxy init..
Welcome to deluge-shell. Type 'help' to see a list of available commands.
Traceback (most recent call last):
  File "/usr/bin/deluge", line 8, in 
    load_entry_point('deluge==1.0.5', 'console_scripts', 'deluge')()
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/main.py", line 99, in start_ui
    UI(options, args)
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/ui/ui.py", line 70, in __init__
    ui = NullUI(args)
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/ui/null/deluge_shell.py", line 470, in __init__
    readline.read_init_file()
IOError: [Errno 2] No such file or directory

When we look at the python readline documentation we see the following:

readline.read_init_file([filename])
    Parse a readline initialization file. The default filename is the last filename used.

It seems that there is a readline initialization file missing on the box (probably it was outside the /mnt/C/sys directory tree and so was not transferred to the box).

Let's try to replicate the problem directly from python console:

box# python
Python 2.5.2 (r252:60911, Dec  8 2008, 07:26:01)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.read_init_file()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory

When I tried it on the colinux system, everything was ok:

dev# python
Python 2.5.2 (r252:60911, Dec  8 2008, 07:26:01)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.read_init_file()
>>>

Hopefully the system call trace will help:

box# strace -o readline-init.txt python
Python 2.5.2 (r252:60911, Dec  8 2008, 07:26:01)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.read_init_file()
Traceback (most recent call last):
  File "<stdin>", line 1, in 
IOError: [Errno 2] No such file or directory
>>>

Let's look at the end of the trace log:

box# tail -n 100 readline-init.txt
...
rt_sigprocmask(SIG_BLOCK, [INT], [RTMIN], 8) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL}, {0x40139066, [], SA_RESTORER|SA_RESTART, 0x401c45a8}, 8) = 0
time(NULL)                              = 1228752774
stat("/mnt/C/sys/root/.inputrc", 0xbffff4ec) = -1 ENOENT (No such file or directory)
stat("/etc/inputrc", 0xbffff4ec)        = -1 ENOENT (No such file or directory)
write(2, "Traceback (most recent call last"..., 35) = 35
...
write(2, "  File \"<stdin>\", line 1, in <mo"..., 38) = 38
write(2, "IOError", 7)                  = 7
write(2, ": ", 2)                       = 2
write(2, "[Errno 2] No such file or direct"..., 35) = 35
write(2, "\n", 1)                       = 1
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_BLOCK, [INT], [RTMIN], 8) = 0
ioctl(0, TIOCGWINSZ, {ws_row=31, ws_col=84, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, TIOCSWINSZ, {ws_row=31, ws_col=84, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x40139066, [], SA_RESTORER|SA_RESTART, 0x401c45a8}, {SIG_DFL}, 8) = 0
write(1, ">>> ", 4)                     = 4
select(1, [0], NULL, NULL, NULL)        = 1 (in [0])
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
read(0, "\4", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, [INT], [RTMIN], 8) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL}, {0x40139066, [], SA_RESTORER|SA_RESTART, 0x401c45a8}, 8) = 0
write(2, "\n", 1)                       = 1
rt_sigaction(SIGINT, {SIG_DFL}, {0x40139066, [], SA_RESTORER, 0x401c45a8}, 8) = 0
munmap(0x402ad000, 16188)               = 0
munmap(0x402b1000, 216100)              = 0
_exit(0)                                = ?

So we found that neither /etc/inputrc nor /mnt/C/sys/root/.inputrc is present on the box and thus the readline initialization complains.

As a solution I choosen to copy the initialization file to root's user directory and re-build the readline package:

dev# cp /etc/inputrc /mnt/C/sys/root/.inputrc
dev# echo "sys/root/.inputrc" >> .filopack/readline-5.2.lst
dev# ./filopack.sh -R --pack readline-5.2

After the re-deployment to the box everything works ok:

dev# deluge --ui=null
[INFO    ] 17:22:53 main:93 Deluge ui 1.0.5
[DEBUG   ] 17:22:53 main:94 options: {'config': None, 'logfile': None, 'ui': 'null'}
[DEBUG   ] 17:22:53 main:95 args: []
[DEBUG   ] 17:22:53 configmanager:44 ConfigManager started..
[INFO    ] 17:22:53 main:98 Starting ui..
[DEBUG   ] 17:22:53 ui:44 UI init..
[DEBUG   ] 17:22:53 configmanager:88 Getting config 'ui.conf'
[DEBUG   ] 17:22:53 config:47 Config created with filename: ui.conf
[DEBUG   ] 17:22:53 config:48 Config defaults: {'default_ui': 'gtk'}
[INFO    ] 17:22:53 ui:68 Starting NullUI..
[DEBUG   ] 17:22:55 client:54 CoreProxy init..
Welcome to deluge-shell. Type 'help' to see a list of available commands.
> help

Available commands:
        * add: Add a torrent
        * config-set: Change a configuration setting
        * configs: Show configuration values
        * connect: Connect to a new deluge server.
        * del: Remove a torrent
        * exit: Exit from the client.
        * halt: Shutdown the deluge server.
        * help: Show help
        * info: Show information about the torrents
        * pause: Pause a torrent
        * quit: Exit from the client.
        * resume: Resume a torrent
        * rm: Remove a torrent

> connect


> info

*** ID: 33820db6dd5e5928d23bc811bbac2f4ae94cb882
*** Name: ubuntu-8.10-desktop-i386.iso
*** Path: torrentfiles
*** Completed: 0.0 KiB/698.8 MiB
*** Status: Paused


> resume

Usage: resume  [ ...]


> resume 33820db6dd5e5928d23bc811bbac2f4ae94cb882


> info

*** ID: 33820db6dd5e5928d23bc811bbac2f4ae94cb882
*** Name: ubuntu-8.10-desktop-i386.iso
*** Path: torrentfiles
*** Completed: 2.1 MiB/698.8 MiB
*** Status: Downloading
*** Download Speed: 60.9 KiB/s
*** Upload Speed: 0.0 KiB/s
*** ETA: 3h 15m


> exit

Thanks
box#

That's all for now.

WMU-6500FS - built sw - readline-5.2

2008-12-08T17:40:00.009+01:00

[Homepage]

[files] [binary]

First we initialize the package timestamp:

dev# cd /mnt/C/
dev# ./filopack.sh --init readline-5.2
Configuration file .filopack/.config file found and used
Timestamp written to file .filopack/readline-5.2.ts

Now we can download and extract the source to the /usr/local/src directory:

dev# cd /usr/local/src
dev# wget ftp://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
--06:08:23--  ftp://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
           => `readline-5.2.tar.gz'
Resolving ftp.gnu.org... 140.186.70.20
Connecting to ftp.gnu.org[140.186.70.20]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /gnu/readline ... done.
==> PORT ... done.    ==> RETR readline-5.2.tar.gz ... done.
Length: 2,037,705 (unauthoritative)

100%[===============================================================================================================================>] 2,037,705      4.38K/s    ETA 00:00

06:20:28 (2.75 KB/s) - `readline-5.2.tar.gz' saved [2037705]

dev# tar xzvf readline-5.2.tar.gz
...

Configuration and build process is straightforward:

dev# cd readline-5.2
dev# ./configure --prefix=/mnt/C/sys
...
dev# make
...
dev# make install
...

Now we go back to the /mnt/C directory and finish the package creation:

dev# cd /mnt/C/
dev# ./filopack.sh --pack readline-5.2
Configuration file .filopack/.config file found and used
-rw-r--r-- root/root    308780 2008-12-08 06:26:38 sys/lib/libreadline.a
-rw-r--r-- root/root     37294 2008-12-08 06:26:38 sys/lib/libhistory.a
lrwxrwxrwx root/root         0 2008-12-08 06:26:38 sys/lib/libhistory.so.5 -> libhistory.so.5.2
-r-xr-xr-x root/root     34696 2008-12-08 06:26:38 sys/lib/libhistory.so.5.2
lrwxrwxrwx root/root         0 2008-12-08 06:26:38 sys/lib/libhistory.so -> libhistory.so.5
-r-xr-xr-x root/root    249866 2008-12-08 06:26:38 sys/lib/libreadline.so.5.2
lrwxrwxrwx root/root         0 2008-12-08 06:26:38 sys/lib/libreadline.so.5 -> libreadline.so.5.2
lrwxrwxrwx root/root         0 2008-12-08 06:26:38 sys/lib/libreadline.so -> libreadline.so.5
-rw-r--r-- root/root     38459 2008-12-08 06:26:38 sys/man/man3/readline.3
-rw-r--r-- root/root     21769 2008-12-08 06:26:38 sys/man/man3/history.3
-rw-r--r-- root/root      2977 2008-12-08 06:26:38 sys/include/readline/rltypedefs.h
-rw-r--r-- root/root      4684 2008-12-08 06:26:38 sys/include/readline/chardefs.h
-rw-r--r-- root/root     10207 2008-12-08 06:26:38 sys/include/readline/history.h
-rw-r--r-- root/root      3529 2008-12-08 06:26:38 sys/include/readline/keymaps.h
-rw-r--r-- root/root     34515 2008-12-08 06:26:38 sys/include/readline/readline.h
-rw-r--r-- root/root      2305 2008-12-08 06:26:38 sys/include/readline/rlconf.h
-rw-r--r-- root/root      1503 2008-12-08 06:26:38 sys/include/readline/rlstdc.h
-rw-r--r-- root/root      3167 2008-12-08 06:26:38 sys/include/readline/tilde.h
-rw-r--r-- root/root    192320 2008-12-08 06:26:38 sys/info/readline.info
-rw-r--r-- root/root     72955 2008-12-08 06:26:38 sys/info/rluserman.info
-rw-r--r-- root/root     58583 2008-12-08 06:26:38 sys/info/history.info

One more thing we have to do is to copy the readline initialization file to the root's directory, add it to the .lst file and re-build the package:

dev# cp /etc/inputrc /mnt/C/sys/root/.inputrc
dev# echo "sys/root/.inputrc" >> .filopack/readline-5.2.lst
dev# ./filopack.sh -R --pack readline-5.2

2008-12-04T14:41:00.035+01:00

Questions and answers

This post will contain answers for some questions, which can be interesting for others and which are more elaborated so that their scope exceeds a limit reasonable for ordinary comments.

Deluge installation, missing pkg_resources package

Q:

Hi Filodej,
thanks a lot for your reply. I got stuck when i was building the Apache files.
I don't know much about linux, but i'll try and i'll let you know if i get Deluge running

I'm planning to do this:

1.- Flash WMU box with Joker Firmware (already done w/o problems)

2.- Uncompress the binary files that you already build inside the WMU box (i'm not gonna use the chroot-ed system with uClibc library under Kubuntu)
For example:
tar xvzf binary_file

where binary_file are the following dependencies

X.Org
Gtk+
boost
python
pycairo
pygtk
atk
glade
pygobject
pyxdg
DBus
DBus-glib
DBus-python

I'll follow the order you set in your blog

3.- Modify configuration files or set environment variables (if any)

And that's all. I don't know if i can do this, or if i'm missing something. Hope this works! 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Filodej,

i tried what i told you before. I uncompress the binaries and i got an error like "can't load library 'librt.so.0'"
So, i uncompress libs-essential-20080502.tar.bz2 and that fixed the error. But now, when i try to run Deluge i get this error:


[root@Nas_Storage site-packages]# deluge
Traceback (most recent call last):
File "/usr/bin/deluge", line 5, in < module >
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

I couldn't see that error on your blog and couldn't find any clue to help me solve this, do you have any idea about how to dix this?
Thanks a lot, and sorry for my qustions

Edgard

A:

The pkg_resources is a part of python setuptools package, you have to install it. I have install it during the Trac installation and so did not encounter this dependency, sorry for that.

When I try it on a relatively clean debian installation (with python 2.5 already installed), I get the same error:

debian:~# python2.5
Python 2.5 (release25-maint, Jul 20 2008, 20:47:25)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named pkg_resources
>>>

In order to install the setuptools package we can follow the installation instructions or as described in the Trac installation (setuptools section) use the ez_setup.py script:

First, we have to download it:

debian:~# cd /tmp
debian:/tmp# wget http://peak.telecommunity.com/dist/ez_setup.py
--04:10:59--  http://peak.telecommunity.com/dist/ez_setup.py
           => `ez_setup.py'
Resolving peak.telecommunity.com... 209.190.5.234
Connecting to peak.telecommunity.com|209.190.5.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,716 (9.5K) [text/plain]

100%[=======================================================================================================>] 9,716         24.97K/s

04:11:00 (24.97 KB/s) - `ez_setup.py' saved [9716/9716]

Now we can try to launch it:

debian:/tmp# python2.5 ez_setup.py
Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c9-py2.5.egg
error: invalid Python installation: unable to open /usr/include/python2.5/pyconfig.h (No such file or directory)

It seems we are missing some python C headers, we have to install the package with python 2.5 header files:

debian:/tmp# apt-get install python2.5-dev
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  python2.5-dev
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.
Need to get 0B/1676kB of archives.
After unpacking 5349kB of additional disk space will be used.
Selecting previously deselected package python2.5-dev.
(Reading database ... 25024 files and directories currently installed.)
Unpacking python2.5-dev (from .../python2.5-dev_2.5-5+etch1_i386.deb) ...
Setting up python2.5-dev (2.5-5+etch1) ...

Now try it again:

debian:/tmp# python2.5 ez_setup.py
Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c9-py2.5.egg
Processing setuptools-0.6c9-py2.5.egg
Copying setuptools-0.6c9-py2.5.egg to /usr/lib/python2.5/site-packages
Adding setuptools 0.6c9 to easy-install.pth file
Installing easy_install script to /usr/bin
Installing easy_install-2.5 script to /usr/bin

Installed /usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg
Processing dependencies for setuptools==0.6c9
Finished processing dependencies for setuptools==0.6c9

Now we can test whether the installation was sucessful:

debian:/tmp# python2.5
Python 2.5 (release25-maint, Jul 20 2008, 20:47:25)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>>

GCC package is huge, is it really necessary?

Q:

Anonymous said... 
    ... 
    I tried to download 'gcc' from you site but the files seems to be corrupted. Do you have nay ideas ?

    below is a screen-shot from my machine:

    $ tar xjvf gcc-4.1.2-sjlj.tar.bz2.tar
    sys/bin/c++
    sys/bin/cpp
    sys/bin/g++
    sys/bin/gcc
    sys/bin/gccbug
    sys/bin/gcov
    sys/bin/i386-linux-uclibc-c++
    sys/bin/i386-linux-uclibc-g++
    sys/bin/i386-linux-uclibc-gcc
    sys/bin/i386-linux-uclibc-gcc-4.1.2
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/README
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/float.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/iso646.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/stdarg.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/stdbool.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/stddef.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/varargs.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/mmintrin.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/mm3dnow.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/xmmintrin.h
    sys/lib/gcc/i386-linux-uclibc/4.1.2/install-tools/include/emmintrin.h
    tar: Decompression failed
    tar: Unable to read all data
    tar: Unable to read all data

    regards,
    Christos

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anonymous said...

    oops...sorry file was corrupted during download - apologies.
    Christos

A:

The truth is that the gcc package is huge (~25MB) though there are just few libraries for deluge. I am going to address this issue so that I cut just a few relevant libraries out of the huge gcc package and provide a new package (~1MB) for it. Following text is by no means necessary for the successful installation, I am just going to describe the process of cutting out relevant dependencies for interested...

First we can list the installed packages. It is possible to use the filopack script for it:

box# cd /mnt/C
box# ./filopack --summary
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)

Filodej package summary:
Package name                          downloaded [#installed/#total]
--------------------------------------------------------------------
...
gcc-4.1.2-sjlj                            no           [ 546/ 549]
...

Now we can uninstall the package:

box# ./filopack.sh --remove gcc-4.1.2-sjlj
Configuration file .filopack/.config file found and used
Sure to remove gcc-4.1.2-sjlj locally at /mnt/C (y/n)?y

Let's make sure the package is actually removed:

box# ./filopack.sh --summary
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)

Filodej package summary:
Package name                          downloaded [#installed/#total]
--------------------------------------------------------------------
...
gcc-4.1.2-sjlj                            no           [   0/ 549]
...

Ok, now when we try to run deluge, we get the "missing library" error message:

box# deluged.sh
/usr/bin/python: can't load library 'libstdc++.so.6'

It seems we need at least the libstdc++.so.6 library. Let's find all the related files:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep  libstdc++
sys/lib/libstdc++.a
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6
sys/lib/libstdc++.la

We actually do not need the static libraries (unless we have a plan to build something directly on the box), so we are interested just in so files:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep  libstdc++*.so
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6

Let's make a new lst file representing the new package deluge-1.0.5-gcclibs we are going to create. This file will contain a list of all the relevant libraries:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep  libstdc++*.so > .filopack/deluge-1.0.5-gcclibs.lst

... and extract just those files from the gcc-4.1.2-sjlj package:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep libstdc++*.so | xargs tar -xjvf gcc-4.1.2-sjlj.tar.bz2
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6

When we try to start deluge daemon again:

box# deluged.sh
/usr/bin/python: Can't resolve symbol '_Unwind_SjLj_Register'

... it seems there are still some missing libraries (or more likely some missing symbols in an older version of the same library). Let's look at the dependencies more closer:

box# LD_TRACE_LOADED_OBJECTS=1 deluged.sh
        /usr/lib/libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40007000)
        /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0 => /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0 (0x40030000)
        libpython2.5.so.1.0 => /mnt/C/sys/lib//libpython2.5.so.1.0 (0x4003f000)
        libpthread.so.0 => /mnt/C/sys/lib//libpthread.so.0 (0x40166000)
        libdl.so.0 => /lib/libdl.so.0 (0x40178000)
        libutil.so.0 => /mnt/C/sys/lib//libutil.so.0 (0x4017b000)
        libm.so.0 => /lib/libm.so.0 (0x4017d000)
        libc.so.0 => /lib/libc.so.0 (0x4018b000)
        libcrypto.so.0.9.7 => /mnt/C/sys/lib//libcrypto.so.0.9.7 (0x4021f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x402f4000)
        libboost_system-gcc41-mt-1_35.so.1.35.0 => /mnt/C/sys/lib//libboost_system-gcc41-mt-1_35.so.1.35.0 (0x402fc000)
        librt.so.0 => /mnt/C/sys/lib//librt.so.0 (0x40300000)
        libstdc++.so.6 => /mnt/C/sys/lib//libstdc++.so.6 (0x40302000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)

Here is a list of libraries present in the gcc package:

dev# cat .filopack/gcc-4.1.2-sjlj.lst | grep "\.so"
sys/lib/libgcc_s.so
sys/lib/libgcc_s.so.1
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6
sys/lib/libmudflap.so.0.0.0
sys/lib/libmudflap.so.0
sys/lib/libmudflap.so
sys/lib/libmudflapth.so.0.0.0
sys/lib/libmudflapth.so.0
sys/lib/libmudflapth.so
sys/lib/libssp.so.0.0.0
sys/lib/libssp.so.0
sys/lib/libssp.so

The libgcc_s looks like a good candidate. We can look for the missing symbol:

box# nm /lib/libgcc_s.so.1
nm: /lib/libgcc_s.so.1: no symbols

box# nm --dynamic /lib/libgcc_s.so | grep Unwind
00003ebc T _Unwind_Backtrace
00003e98 T _Unwind_DeleteException
00002800 T _Unwind_FindEnclosingFunction
00004e2c T _Unwind_Find_FDE
00003c50 T _Unwind_ForcedUnwind
000027dc T _Unwind_GetCFA
00002838 T _Unwind_GetDataRelBase
00003f60 T _Unwind_GetGR
00003f84 T _Unwind_GetIP
000027e8 T _Unwind_GetLanguageSpecificData
000027f4 T _Unwind_GetRegionStart
00002844 T _Unwind_GetTextRelBase
00003a08 T _Unwind_RaiseException
00003d00 T _Unwind_Resume
00003dc8 T _Unwind_Resume_or_Rethrow
00003f70 T _Unwind_SetGR
00003f90 T _Unwind_SetIP

The /lib/libgcc_s.so is an "old" version of the library being replaced by the new one contained in the gcc package. Apparently the symbol '_Unwind_SjLj_Register' is missing in the list, but there are similar symbols.
Let's list the libgcc related files:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep libgcc_s*.so
sys/lib/libgcc_s.so
sys/lib/libgcc_s.so.1

Now we can extract the files from the package tarball:

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep libgcc_s*.so | xargs tar -xjvf gcc-4.1.2-sjlj.tar.bz2
sys/lib/libgcc_s.so
sys/lib/libgcc_s.so.1

Make sure that the symbol is actually there:

box# nm --dynamic /mnt/C/sys/lib/libgcc_s.so | grep Unwind
00005361 T _Unwind_Backtrace
00005345 T _Unwind_DeleteException
0000522e T _Unwind_FindEnclosingFunction
00004e4b T _Unwind_Find_FDE
000051d6 T _Unwind_GetCFA
00005235 T _Unwind_GetDataRelBase
000051c5 T _Unwind_GetGR
000051fb T _Unwind_GetIP
0000521a T _Unwind_GetLanguageSpecificData
00005227 T _Unwind_GetRegionStart
0000523c T _Unwind_GetTextRelBase
000051e7 T _Unwind_SetGR
00005209 T _Unwind_SetIP
000054a5 T _Unwind_SjLj_ForcedUnwind
000054ef T _Unwind_SjLj_RaiseException
0000511c T _Unwind_SjLj_Register
00005452 T _Unwind_SjLj_Resume
0000557d T _Unwind_SjLj_Resume_or_Rethrow
000051ba T _Unwind_SjLj_Unregister

Now we can append the files to the lst file.

box# cat .filopack/gcc-4.1.2-sjlj.lst | grep libgcc_s*.so >> .filopack/deluge-1.0.5-gcclibs.lst

And test the deluge again:

[root@storage C]# deluged.sh

... now the daemon starts without problems.
The last step is to create the deluge-1.0.5-gcclibs package.

box# cat .filopack/deluge-1.0.5-gcclibs.lst
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6
sys/lib/libgcc_s.so
sys/lib/libgcc_s.so.1

We can use the --pack action of the filopack script with -R option in order to reuse the (already created) lst file:

box# ./filopack.sh -R --pack deluge-1.0.5-gcclibs
Configuration file .filopack/.config file found and used
tar: unrecognized option `--files-from=.filopack/deluge-1.0.5-gcclibs.lst'
BusyBox v1.90-JKR (2008.04.09-06:53 CET) multi-call binary

Usage: tar -[czjZxtvO] [-f TARFILE] [-C DIR] [FILE(s)] ...

Create, extract, or list files from a tar file.

Options:
        c               create
        x               extract
        t               list

Archive format selection:
        z               Filter the archive through gzip
        j               Filter the archive through bzip2
        Z               Filter the archive through compress

File selection:
        f               name of TARFILE or "-" for stdin
        O               extract to stdout
        C               change to directory DIR before operation
        v               verbosely list files processed

... oops, it seems that I have different versions of tar on my box and on my dev# system (Chroot-ed environment on top of the Colinux with Debian), there the --files-from works ok.
Let's make sure. First find the tar on the box:

box# which tar
/bin/tar
box# ls -l /bin/tar
lrwxrwxrwx 1 root root 7 2008-05-21 13:40 /bin/tar -> busybox

And now on the dev# system:

dev# tar --version
tar (GNU tar) 1.15.1

dev# which tar
/bin/tar

dev# ls -l /bin/tar
-rwxr-xr-x  1 root root 166880 Apr 16  2008 /bin/tar*

As a solution I have updated the filopack script to be compliant with the busybox tar version. I changed the following statement:

tar $PACK_CMD $PACKAGE.$EXT --files-from $CONFIG_DIR/$PACKAGE.lst 2>&1 | tee $CONFIG_DIR/$PACKAGE.err

to the following:

cat $CONFIG_DIR/$PACKAGE.lst | xargs tar $PACK_CMD $PACKAGE.$EXT 2>&1 | tee $CONFIG_DIR/$PACKAGE.err

.. the only thing I am not sure of is whether the number of command line argument is somewhat limited; such limitation could cause some problems for packages with many files.
Let's try it directly:

box# ./filopack.sh -R --pack deluge-1.0.5-gcclibs
Configuration file .filopack/.config file found and used
tar: Creating bzip2 compressed archives is not currently supported.

Equivalent command:
cat .filopack/deluge-1.0.5-gcclibs.lst | xargs tar cjvf deluge-1.0.5-gcclibs.tar.bz2

Bzip compression is not supported, so try the tgz:

box# ./filopack.sh -R -o tgz --pack deluge-1.0.5-gcclibs
Configuration file .filopack/.config file found and used
sys/lib/libgcc_s.so.1
sys/lib/libgcc_s.so
sys/lib/libstdc++.so.6
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so

Equivalent command:
cat .filopack/deluge-1.0.5-gcclibs.lst | xargs tar czvf deluge-1.0.5-gcclibs.tgz

... this works. We have successfully created the package.
Note: Finally I created the bz2 version on my mirror system.

dev# ./filopack.sh -R --pack deluge-1.0.5-gcclibs
...

So, that's all for now. I have uploaded the package and now it is publicly available:

box# ./filopack.sh --packages
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Available packages:
...
deluge-1.0.5
deluge-1.0.5-deplibs
...

You can download it to your box:

box# ./filopack.sh --download deluge-1.0.5-gcclibs
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package deluge-1.0.5-gcclibs from http://filodej.ic.cz ...
connected!

Length: 113 [text/plain]
connected!

Length: 1,191,263 [application/x-tar]

And install it as follows:

box# ./filopack.sh --install deluge-1.0.5-gcclibs
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack deluge-1.0.5-gcclibs locally at /mnt/C (y/n)?y
sys/lib/libstdc++.so
sys/lib/libstdc++.so.6.0.8
sys/lib/libstdc++.so.6
sys/lib/libgcc_s.so
sys/lib/libgcc_s.so.1

Unresolved 'PyUnicodeUCS2_DecodeUTF8' symbol

Q:

$ deluged.sh
/usr/bin/python: Can't resolve symbol '_Unwind_SjLj_Register'
$
$
$ LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0 /usr/lib/libgcc_s.so" deluged -d
[DEBUG ] 08:53:55 configmanager:44 ConfigManager started..
[INFO ] 08:53:55 daemon:44 Deluge daemon 1.0.5
[DEBUG ] 08:53:55 daemon:45 options: {'logfile': None, 'config': None, 'port': None, 'donot': True}
[DEBUG ] 08:53:55 daemon:46 args: []
/usr/bin/python: can't resolve symbol 'PyUnicodeUCS2_DecodeUTF8'
$

A:

Likely this symbol should be defined in python library. Let's look if it is the case:

box# nm /mnt/C/sys/lib/libpython2.5.so.1.0 | grep DecodeUTF8
00073f08 T PyUnicodeUCS4_DecodeUTF8
00073f30 T PyUnicodeUCS4_DecodeUTF8Stateful

So it seems there is a UCS4 vs. UCS2 mismatch on your system. When I googled PyUnicodeUCS4 PyUnicodeUCS2 I got the following explanation:

You are using a version of Python that uses a 4-byte representation for Unicode characters, but some C extension module you are importing was compiled using a Python that uses a 2-byte representation for Unicode characters (the default).

So it seems to be exactly the case on your system. Look at the python console just to make sure:

box# python
Python 2.5.2 (r252:60911, May  3 2008, 16:19:27)
[GCC 3.3.6] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.maxunicode > 65535 and 'UCS4 build' or 'UCS2 build'
UCS4 build
>>>

Now we have to find out what is the python extension to be blamed, but unfortunately I cannot do it on my own since it seems there is no such problem on my box. At least I can try to help you a bit how to investigate that.

You can use strace (system calls and signals tracer) for that. Here is the a short explanation how I built it and here you can directly download the package, or possibly if you are using the filopack system you can simply write:

$ cd /mnt/C
$ ./filopack.sh --download strace-4.5.15
$ ./filopack.sh --install strace-4.5.15

... and (hopefully) you are prepared.

To replicate a scenario similar to yours, I can run the deluge daemon without the LD_PRELOAD prefix, in such case I am also missing some symbols:

box# /usr/bin/deluged
box# /usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

So now I can try to trace all the system calls:

box# strace /usr/bin/deluged
...
stat64("/mnt/C/sys/root/.config/deluge", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fork()                                  = 17025
_exit(0)                                = ?
Process 17020 detached
box# /usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

It seems that the loader problem was in another instance of deluged process. Let's look at strace help to see what we can do about it:

box# strace -h
usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file]
              [-p pid] ... [-s strsize] [-u username] [-E var=val] ...
              [command [arg ...]]
   or: strace -c [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ...
              [command [arg ...]]
-c -- count time, calls, and errors for each syscall and report summary
-f -- follow forks, -ff -- with output into separate files
-F -- attempt to follow vforks, -h -- print help message
-i -- print instruction pointer at time of syscall
-q -- suppress messages about attaching, detaching, etc.
-r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs
-T -- print time spent in each syscall, -V -- print version
-v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args
-x -- print non-ascii strings in hex, -xx -- print all strings in hex
-a column -- alignment COLUMN for printing syscall results (default 40)
-e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]...
   options: trace, abbrev, verbose, raw, signal, read, or write
-o file -- send trace output to FILE instead of stderr
-O overhead -- set overhead for tracing syscalls to OVERHEAD usecs
-p pid -- trace process with process id PID, may be repeated
-s strsize -- limit length of print strings to STRSIZE chars (default 32)
-S sortby -- sort syscall counts by: time, calls, name, nothing (default time)
-u username -- run command as username handling setuid and/or setgid
-E var=val -- put var=val in the environment for command
-E var -- remove var from the environment for command

Now we can give it another try, this time with the -f option:

box# strace -f /usr/bin/deluged
...
...
close(7)                                = 0
munmap(0x40006000, 4096)                = 0
open("./libbz2.so.1.0", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/mnt/C/sys/lib//libbz2.so.1.0", O_RDONLY) = 7
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0$\21\0\000"..., 4096) = 4096
old_mmap(NULL, 57344, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40e57000
old_mmap(0x40e57000, 52556, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x40e57000
old_mmap(0x40e64000, 3712, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0xd000) = 0x40e64000
close(7)                                = 0
munmap(0x40006000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
write(2, "", 0)                         = 0
write(2, "/usr/bin/python", 15/usr/bin/python)         = 15
write(2, ": can\'t resolve symbol \'", 24: can't resolve symbol ') = 24
write(2, "__cxa_pure_virtual", 18__cxa_pure_virtual)      = 18
write(2, "\'\n", 2'
)                     = 2
munmap(0x40006000, 4096)                = 0
_exit(1)                                = ?
Process 17039 detached

Most likely the libbz2.so module is requiring the unresolved __cxa_pure_virtual symbol.

Back to your problem, once we know the particular python extension requiring the 2 byte unicode version of the DecodeUTF8 method we can try to re-build or re-install it appropriately...

Part II.

Dear Filodej,

you are right! I have followed your instructions and indeed this is the problem. 
I hope that the console output after executing strace commandes would be found 
usefull for you.
Here is the complete output from executing strace, and here for the strace -f.

Thank you in advance, for helping me out :-) hope others will benefit as well.

Regards,
Christos

Good, so the relevent part of your trace is here:

$ strace -f /usr/bin/deluged
execve("/usr/bin/deluged", ["/usr/bin/deluged"], [/* 31 vars */]) = 0
...
ioctl(9, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffeddc8) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(9, {st_mode=S_IFREG|0755, st_size=411371, ...}) = 0
open("/usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so", O_RDONLY) = 10
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0$7\0\000"..., 4096) = 4096
old_mmap(NULL, 180224, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4059c000
old_mmap(0x4059c000, 167720, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 10, 0) = 0x4059c000
old_mmap(0x405c5000, 9872, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 10, 0x29000) = 0x405c5000
close(10)                               = 0
munmap(0x40006000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
write(2, "", 0)                         = 0
write(2, "/usr/bin/python", 15/usr/bin/python)         = 15
write(2, ": can\'t resolve symbol \'", 24: can't resolve symbol ') = 24
write(2, "PyUnicodeUCS2_DecodeUTF8", 24PyUnicodeUCS2_DecodeUTF8) = 24
write(2, "\'\n", 2'
)                     = 2
munmap(0x40006000, 4096)                = 0
_exit(1)                                = ?
Process 2748 detached

I wonder where did you get the pyexpat library since I did not build the PyXML as part of my python package. Let's look at the JoKeR's package (it seems as a good candidate):

box# wget http://mgb111.pradnik.net/addons/soft-lang/Python-25-PyXML-084.tar.gz
connected!

Length: 17,194,098 [application/x-gzip]

box# tar tzf Python-25-PyXML-084.tar.gz | grep pyexpat
./sys/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
./sys/lib/python2.5/site-packages/_xmlplus/sax/drivers/drv_pyexpat.py
./sys/lib/python2.5/site-packages/_xmlplus/sax/drivers/drv_pyexpat.pyc
./sys/lib/python2.5/site-packages/_xmlplus/sax/drivers2/drv_pyexpat.py
./sys/lib/python2.5/site-packages/_xmlplus/sax/drivers2/drv_pyexpat.pyc
./sys/lib/python2.5/test/output/test_pyexpat
./sys/lib/python2.5/test/test_pyexpat.py
./sys/lib/python2.5/test/test_pyexpat.pyc
./sys/lib/python2.5/test/test_pyexpat.pyo
./sys/lib/python2.5/lib-dynload/pyexpat.so

Bingo! You probably did not remove the JoKeR's installation and just extract my python package over it.
Since I have built python with different unicode settings that JoKeR (it is nothing like Microsoft's intended incompatibilities, I swear I had no idea about it at the time ;-) now you are experiencing the missing symbol(s).

Just to make sure I am right in my assumption, I try to replicate your problem on my box. Let's extract the _xmlplus directory from JoKeR's package:

box# tar xzvf Python-25-PyXML-084.tar.gz ./sys/lib/python2.5/site-packages/_xmlplus/*
...

Now I can try to do some python xml parsing and see what happens:

box# strace -o st.txt /usr/bin/python
Python 2.5.2 (r252:60911, May  3 2008, 16:19:27)
[GCC 3.3.6] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> xml.dom.minidom.parseString( 'test')
/usr/bin/python: can't resolve symbol 'PyUnicodeUCS2_DecodeUTF8'

Great, now I am in the same trouble as you ;-)
Let's look at the trace log:

box# tail -n 20 st.txt
stat64("/usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat", 0xbfff4a4c) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfff49e8) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(5, {st_mode=S_IFREG|0755, st_size=411371, ...}) = 0
open("/usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so", O_RDONLY) = 6
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0$7\0\000"..., 4096) = 4096
old_mmap(NULL, 180224, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40310000
old_mmap(0x40310000, 167720, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 6, 0) = 0x40310000
old_mmap(0x40339000, 9872, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x29000) = 0x40339000
close(6)                                = 0
munmap(0x40006000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
write(2, "", 0)                         = 0
write(2, "/usr/bin/python", 15)         = 15
write(2, ": can\'t resolve symbol \'", 24) = 24
write(2, "PyUnicodeUCS2_DecodeUTF8", 24) = 24
write(2, "\'\n", 2)                     = 2
munmap(0x40006000, 4096)                = 0
_exit(1)                                = ?

and try to launch the deluge daemon:

box# deluged.sh
box# /usr/bin/python: can't resolve symbol 'PyUnicodeUCS2_DecodeUTF8'

Ok, now I am pretty sure this is exactly your situation. Let's remove the _xmlplus package again, we cannot use it anyway, since it is built incompatibly with the rest of the python framework:

box# rm -d -r ./sys/lib/python2.5/site-packages/_xmlplus/

Now let's try the xml parsing and launch the deluge daemon again:

box# python
Python 2.5.2 (r252:60911, May  3 2008, 16:19:27)
[GCC 3.3.6] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> xml.dom.minidom.parseString( '<a>test</a>')
<xml.dom.minidom.Document instance at 0x4027940c>
>>>

box# deluged.sh
box#

Everything works again.

The removal of the _xmlplus pyhon package should help in your case as well, but note that there could be other incompatible files. The ultimate solution would be to remove both python packages (mine and JoKeR's) and install just mine again. In case you needed the PyXML package (which seems unlikely to me, since it does not work for you anyway) I could sometimes build one compatible with 4-byte unicode.

Unresolved 'g_assertion_message_expr' symbol

Q:

Hello again,

I have erased everything from my box in order to perform a clean installation based on your instructions. 
Unfortunately, this didn't go as it was expected.
Initially I installed Deluge and all of the dependencies, apart from setuptools. 
This was due to the fact that I couldn't run python cause there was a library .so-something missing 
- unfortunately I did not write down the name.
In order to fix this (and hopefully it was fixed) I downloaded & installed Joker's "minimal-config" & "libs-essential".

Now when I run:
LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0 /usr/lib/libgcc_s.so" deluged -d

I am getting the following error:
/usr/bin/python: can't resolve symbol 'g_assertion_message_expr'
...
regards,
Christos

A:

First I googled a bit and found that the g_assertion_message_expr symbol should be present in the libglib-2.0.so library. It seemed little bit weird that you are experiencing such error, since this library is listed in my list of dependencies. It is clear that it needs a deeper analysis...

First let's make sure the libglib library is really present on the system:

box# ls -l /mnt/C/sys/lib/libglib*
-rwxr-xr-x 1 root root     878 2008-06-30 00:06 /mnt/C/sys/lib/libglib-2.0.la
lrwxrwxrwx 1 root root      23 2008-12-03 23:04 /mnt/C/sys/lib/libglib-2.0.so -> libglib-2.0.so.0.1702.0
lrwxrwxrwx 1 root root      23 2008-12-03 23:04 /mnt/C/sys/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1702.0
-rwxr-xr-x 1 root root 2631967 2008-04-17 12:34 /mnt/C/sys/lib/libglib-2.0.so.0.1400.0
rwxr-xr-x 1 root root 1131687 2008-06-30 00:06 /mnt/C/sys/lib/libglib-2.0.so.0.1702.0

... as can be seen there are two of them but just one of them is linked. This fact could be related to your problem.

We can learn what is present in my glib package:

box# ./filopack.sh --download glib-2.17.2                                 
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package glib-2.17.2 from http://filodej.ic.cz ...
connected!

Length: 21,692 [text/plain]
connected!

Length: 1,947,202 [application/x-tar]

box# tar tjvf glib-2.17.2.tar.bz2 | grep libglib
-rwxr-xr-x 0/0   1131687 2008-06-30 00:06:55 sys/lib/libglib-2.0.so.0.1702.0
lrwxrwxrwx 0/0         0 2008-06-30 00:06:55 sys/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1702.0
lrwxrwxrwx 0/0         0 2008-06-30 00:06:55 sys/lib/libglib-2.0.so -> libglib-2.0.so.0.1702.0
-rwxr-xr-x 0/0       878 2008-06-30 00:06:55 sys/lib/libglib-2.0.la

So we see that the 2.17.2 version comes from my package. What about the other one?

You write that you have downloaded & installed Joker's "minimal-config" & "libs-essential", so let's look at that:

box# wget http://mgb111.pradnik.net/addons/libs-essential-20080502.tar.bz2
connected!

Length: 13,454,268 [application/x-bzip2]

box# tar tjvf libs-essential-20080502.tar.bz2 | grep libglib
-rwxr-xr-x 0/0       834 2008-04-17 12:34:55 ./sys/lib/libglib-2.0.la
lrwxrwxrwx 0/0         0 2008-05-10 20:41:07 ./sys/lib/libglib-2.0.so -> libglib-2.0.so.0.1400.0
lrwxrwxrwx 0/0         0 2008-05-10 20:41:07 ./sys/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1400.0
-rwxr-xr-x 0/0   2631967 2008-04-17 12:34:55 ./sys/lib/libglib-2.0.so.0.1400.0

... ok, so another one (2.14.0 version) is from JoKeR's package.

Let's dig a little bit deeper, what about symbols?

box# nm --dynamic /mnt/C/sys/lib/libglib-2.0.so.0.1702.0 | grep g_assertion_message_expr
0006409b T g_assertion_message_expr
box# nm --dynamic /mnt/C/sys/lib/libglib-2.0.so.0.1400.0 | grep g_assertion_message_expr

so it seems that the g_assertion_message_expr symbol was introduced right between 14.0 and 17.2 versions (or possibly the lack of it in the older version is caused by different build configuration). In any case the problem was caused by the fact that you extracted JoKeR's essential-libs package AFTER my glib package and thus effectively downgraded the glib from 2.17.2 version down to 2.14.0.

Sorry for that complication, I built my system on top of JoKeR's minimal-config and libs-essential and I mention it in the post about the box configuration; but it is sure my fault that I did not mention it explicitly among the deluge dependencies. I am doing it now to prevent further confusion.

That's all for now. You can now redirect the symlinks (libglib-2.0.so and libglib-2.0.so.0) by hand or better re-install my glib package, supposedly it should fix your problem. As can be seen such subtle details like installation order can sometimes make a big difference :-)

Missing bash shell

Q:

...
Anyway, I then ran the "./filopack.sh --download deluge-1.0.5" line, and I got this: "-ash: ./filopack.sh: not found." Now, that's not good, right?

Any idea what it is that I'm doing wrong please?
...

A:

In a bash session with bash shell installed on the system the filopack script is running fine:

box# ./filopack.sh
    
Stupid packaging system (version 0.3.7)

Usage:
 
  filopack.sh [OPTIONS] [] []

Basic usage:
  ...

When we look at the first line of the script there is bash shell specified as an interpreter:

box# head -n1 ./filopack.sh
#!/bin/bash

Let's look where is the bash shell installed:

box# which bash
/usr/bin/bash

The /bin directory is on a read-only file system, but /bin/bash is just a symlink to /usr/bin/bash:

box# ls -l /bin/bash 
lrwxrwxrwx 1 root root 19 2008-05-21 13:40 /bin/bash -> /mnt/C/sys/bin/bash

Let's try to "delete" the bash shell for a moment:

box# mv /usr/bin/bash{,.del}

Now when we try to run the filopack script:

 
box# ./filopack.sh           
-bash: ./filopack.sh: /bin/bash: bad interpreter: No such file or directory

The bash shell (we are still running the bash session even if the bash executable is removed) is sufficiently verbose in its error messages so the cause of the problem is obvious. Let's try the same in ash shell:

box# ash
box$ cd /mnt/C/
box$ ./filopack.sh
ash: ./filopack.sh: not found

Ok now we have replicated your problem. You have to install the bash shell in order to run the filopack script.

WMU-6500FS - Deluge torrent 1.0.5 (part IV)

2008-11-24T22:10:00.048+01:00

Screenshots

Finally I found time to build the full version of deluge bittorrent client (version 1.0.5) and create a package for it.

Deluge 1.0.5 GTK client
(running on CoLinux with Debian 4.0, XMing server running on WinXP) Deluge 1.0.5 GTK client
(running on WinXP) Deluge 1.0.5 GTK client
(running on Ubuntu 8.04)

Build result

[binary] [file list]
Prerequisites: [JoKeR's minimal config] [JoKeR's essential libs]
For filopack system: [JoKeR's bash shell] [JoKeR's busybox extended]
Dependencies: [gcc libraries] [glib] [readline] [boost] [python] [setuptools] [DBus] [DBus-glib] [DBus-python] [pygobject] [pyxdg]
GUI dependencies: [X.Org] [Gtk+] [pycairo] [pygtk] [atk] [glade]
Edit: Regarding to this post it seems that [pygobject] and [pyxdg] packages are needed even for non-gui mode.

Overview

First I'll demonstrate the shortest path (given all the needed dependencies are already installed). Then I describe the build and package creation process, since I feel that such information can be helpful when something goes wrong.

Download & Install

We can utilize the filopack system for that purpose. In case we do not have it we can simply download it (and make executable) as follows:

box# cd /mnt/C
box# wget http://filodej.ic.cz/filopack/filopack.sh
box# chmod 755 filopack.sh

First action we have to do is to uninstall the previous Deluge version (assumed we have both Deluge 0.9.03 and ./filopack.sh installed on the box):

box# cd /mnt/C
box# ./filopack.sh --remove deluge-0.9.03
Configuration file .filopack/.config file found and used
Sure to remove deluge-0.9.03 locally at /mnt/C (y/n)?y
...

Now we can download the package:

box# cd /mnt/C
box# ./filopack.sh --download deluge-1.0.5
[root@storage C]# ./filopack.sh --download deluge-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package deluge-1.0.5 from http://filodej.ic.cz ...
connected!

Length: 68,332 [text/plain]
connected!

Length: 15,645,450 [application/x-tar]

And the last step is to install it:

box# ./filopack.sh --install deluge-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack deluge-1.0.5 locally at /home/petr (y/n)?
...

Now, we are done (if we are lucky ;-)

I added scripts (deluge.sh and deluged.sh) which we can run in place of original loader scripts (deluge and deluged) which are working around the weird problems with dynamic loader missing some symbols.

box# cat /mnt/C/sys/bin/deluged.sh
LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" deluged

So if you already have the /mnt/C/sys/bin/ directory in your PATH now instead of:

box# deluged
/usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

... you can simple type:

box# deluged.sh

It is great that the daemon mode is now supported and we can run the GTK GUI remotely (even so the demands of python runtime are relatively high for the box).
In following figures you can see the clients running on Ubuntu and WinXP both connected to the daemon running on the box. In previous figure there is also the client running on the box - it can be seen that its progress controls are way behind the real time and even the PC running client does not receive much information from the daemon. In such situations everything becomes reaaaalllllly sloooowwww as the box can't catch the train.

It is obvious that it is not a good idea to run GTK client directly on the box, since it pushes its HW resources really to its limits, but in is nice that it (no matter how slowly) works.

Build & Pack

Everything necessary for successful build was already described in previous three parts of this series, this part just collects the information and describes the whole building process step-by-step.

Same as in the previous case we have to uninstall the old Deluge version (0.9.03)

dev# cd /mnt/C
dev# ./filopack.sh --remove deluge-0.9.03
Configuration file .filopack/.config file found and used
Sure to remove deluge-0.9.03 locally at /mnt/C (y/n)?
...

Now we are ready to start the building process. First thing we have to do is to create a timestamp file. With help of this file the packaging system determines what files are included to the resulting package.

dev# ./filopack.sh --init  deluge-1.0.5
Configuration file .filopack/.config file found and used
Timestamp written to file .filopack/deluge-1.0.5.ts

Now we can download and extract the sources.

dev# cd /usr/local/src/
dev# wget http://download.deluge-torrent.org/source/1.0.5/deluge-1.0.5.tar.bz2
...
dev# tar xjvf deluge-1.0.5.tar.bz2
dev# cd /usr/local/src/deluge-1.0.5

We have to do the following steps in order to make a successful build:
(For explanations see previous parts of this series)
Add proper paths to boost header files and libraries

dev# export CFLAGS=-I/mnt/C/sys/include/boost-1_35
dev# export LDFLAGS=-L/mnt/C/sys/lib

Add missing IPV6 related macro to socket.hpp header file:

dev# nano libtorrent/include/libtorrent/socket.hpp
    add:
      #ifndef IPV6_V6ONLY
      #define IPV6_V6ONLY 26
      #endif

Disable the memory debugging (file libtorrent/src/memdebug.cpp) from the build. You can:
- either modify the Makefile
- or clear the memdebug.cpp
- or use the preprocessor condition:

      #if 0
        ...
      #endif

Now we are ready to start the build and installation:

dev# python setup.py build 
...
dev# python setup.py install --prefix=/mnt/C/sys/
...

If the build and installation succeeded, we are almost done. Now, when we try to start the deluge daemon, the dynamic loader is missing some symbols (it was same with previous version, I am possibly doing something wrong but do not know what).

dev# deluged
dev# /usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

At least we have the workaround - library preload, with following triar and error method we get the set of libraries to be rpe-loaded:

dev# LD_PRELOAD=/usr/lib/libstdc++.so.6 deluged
dev# /usr/bin/python: can't resolve symbol 'BIO_free'

dev# LD_PRELOAD="/usr/lib/libstdc++.so.6 /usr/lib/libssl.so.0.9.7" deluged
dev# /usr/bin/python: can't resolve symbol '_ZN5boost6system18get_posix_categoryEv'

dev# LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" deluged

OK, now it works. We can prepare the loader script with previous command-line:

dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" deluged \"\$@\" > /mnt/C/sys/bin/deluged.sh
dev# chmod +x /mnt/C/sys/bin/deluged.sh

Now (if we have the /mnt/C/sys/bin in our PATH) we can run the deluge daemon as follows:

dev# deluged.sh

For deluge client the symbol problem is the same, so we prepare a loader script as well:

dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" \"\$@\" deluge > /mnt/C/sys/bin/deluge.sh
dev# chmod +x /mnt/C/sys/bin/deluge.sh

Now we try to launch the GUI (GTK client) but some problems still remain:

dev# deluge.sh
...
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/common.py", line 142, in get_logo
    size, size)
gobject.GError: Unrecognized image file format

We already solved this problem with previous version, so we know the receipt:

dev# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/common.py

Let's try again:

dev# deluge.sh
...
  self.window.show()
/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/ui/gtkui/mainwindow.py:95: GtkWarning: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed
  self.window.show()
Segmentation fault

We forgot the set up the DISPLAY environment variable properly (Actually I do not know why it crashes in such case, but the truth is that proper DISPLAY setup solves the problem):

dev# export DISPLAY=<x-server-ip>

One more thing we have to do is to let python know the path to the deluge egg:

dev# cd /mnt/C/sys/lib/python2.5/site-packages
dev# echo "./deluge-1.0.5-py2.5-linux-i686.egg" > deluge.pth

Finally we are ready to create the deluge-1.0.5 package:

dev# cd /mnt/C
dev# ./filopack.sh --pack deluge-1.0.5

Remote install

Now we have the package created locally on the "mirror" system (colinux debian in my case). But we have to get it to the box. The filopack script can help us with this task as well.

First we have to uninstall the previous deluge version from the box. We can definitely do it locally on the box itself, but we can also do it remotely:

dev# ./filopack.sh -r --remove deluge-0.9.03
Configuration file .filopack/.config file found and used
Sure to remove deluge-0.9.03 remotely at root@storage:/mnt/C (y/n)?y
...

If we want to make sure that the previously installed software is gone, we can look at the package summary (unfortunately this feature is supported only locally). So from the box shell we can do following:

box# ./filopack.sh --summary
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)

Filodej package summary:
Package name                          downloaded [#installed/#total]
--------------------------------------------------------------------
Mesa-7.0.3                                no           [   0/  49]
MesaDemos-7.0.3                           no           [ 129/ 129]
atk-1.22.0                                no           [ 160/ 160]
audiofile-0.2.6                           no           [   0/  13]
binutils-2.18                             no           [ 140/ 140]
boost-1.35.0                              no           [5195/5195]
cairo-1.6.4                               no           [  76/  76]
code2html-0.9.1                           no           [   2/   2]
cvstrac-2.0.1-3                           no           [   3/   3]
dbus-1.2.1                                no           [  38/  38]
dbus-glib-0.76                            no           [  32/  32]
dbus-python-0.82.4                        no           [  66/  66]
deluge-0.9.03                        no          [   0/ 673]
didiwiki-0.5                              no           [   1/   1]
faad2-2.6.1                               no           [   0/   8]
...

Now we are back in the "mirror" system console and we can upload the (newly created) package to the box:

dev# ./filopack.sh -r --upload deluge-1.0.5 
Configuration file .filopack/.config file found and used
Sure to upload deluge-1.0.5 to root@storage:/mnt/C (y/n)?y
root@storage's password: 
deluge-1.0.5.tar.bz2                                                100%   15MB 318.3KB/s   00:48

And perform the remote installation as well:

dev# ./filopack.sh -r --install deluge-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Module deluge-1.0.5 not found in package list - use 'tar.bz2' extension
Sure to unpack deluge-1.0.5 remotely at root@storage:/mnt/C (y/n)?y
root@storage's password: 
...

Deluge daemon (deluged.sh) now works OK on the box.

The only remaining problem is following. When we run the GTK GUI client (deluge.sh) we get following error:

box# deluge.sh
...
gobject.GError: Failed to open file '/tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/data/pixmaps/inactive16.png': No such file or directory

When we look to the /tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/data/pixmaps/ directory there is not a inactive16.png there is just inactive16.png0000644 file and the same is with checking16.png file.
It seems it is a bug in tar implementation, the file permissions are "leaking out" to the name (see this issue description or this forum).

The solution is easy in this case:

box# mv /tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/data/pixmaps/inactive16.png{0000644,}
box# mv /tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-1.0.5-py2.5-linux-i686.egg/deluge/data/pixmaps/checking16.png{0000644,}

When you run the deluge and it looks similar like this: ... then there are some missing links to font directories:

box# mkdir /usr/share/fonts
box# ln -sn /mnt/C/sys/X11/lib/X11/fonts/OTF /usr/share/fonts/X11-OTF
box# ln -sn /mnt/C/sys/X11/lib/X11/fonts/TTF /usr/share/fonts/X11-TTF

Setup

Now (after the update of the python package) we are able to run the console client right on the box: We can read the configuration options:

>  configs             

* add_paused: False
* allow_remote: False
* auto_managed: True
* autoadd_enable: False
* autoadd_location: C
* compact_allocation: False
* config_location: /mnt/C/sys/root/.config/deluge
...
* daemon_port: 58846
...

If we want access the daemon remotely, we can set it up as follows (of course it is possible to change the port as well):

> config-set allow_remote True

* Configuration value successfully updated.

>  quit 

Thanks
box#

Now we have to restart the daemon (if it is running):

box# killall deluged
box# deluged.sh

... and we are set up to access the daemon remotely (from PC running either Linux or Windows) as can be seen on following screenshots:

Deluge 1.0.5 GTK client
(running on WinXP) Deluge 1.0.5 GTK client
(running on Ubuntu 8.04)

That's all for now.

Simple packaging system

2008-11-21T15:37:00.030+01:00

Overview

In this post I want to describe the filopack bash script, very simple (and stupid) packaging system I have prepared to ease the package manipulation. It is implemented specifically as a helper for packages presented here, but it could be used for any other system as well. It aims to help potential users with the installation process. It would be definitely better to base such a system on a well established package system like for example aptitude, rather than create my own (primitive) system from scratch, but unfortunately I had no time to study the aptitude yet (probably it would be much easier than I imagine) and started to practically learn the bash scripting instead ;-)

Following examples should explain the basic usage of the filopack packaging system. This tool serves for package enumeration, downloading, installation and un-instalation as well as package creation and uploading. However it does not handle dependencies at all, it just simplifies the installation routine, YOU have to know what packages you need.

The system is suitable for usage on the box itself as well as on the chroot-ed "mirror" system. Also besides the downloading and installation of pre-built packages, it can be used for a creation user-built packages from source code. I consider the latter two scenarios as "advanced" and will cover separately from the "basic" usage scenario - it means downloading and installing pre-built packages directly to the box.

Basic usage

In this scenario a user just wants to download and extract a package directly to the WMU box. This section will cover this scenario step by step.

Bash shell

In order to use the filopack script you need to have the bash shell installed on the system. You can use the JoKeR's prebuilt package:

box# cd /mnt/C/
box# wget http://mgb111.pradnik.net/addons/soft-shells/bash-3.2.33-3.tar.gz
box# tar xzvf bash-3.2.33-3.tar.gz
...

Now you can possibly set it as root's and users' shell:

box# nano /mnt/C/sys/etc/env-ng 
...

# change root shell to bash (if exist)
ROOTSHELL=1

# change users shell to bash (if exist)
USERSHELL=1

Busybox extended

box# cd /mnt/C/
box# wget http://mgb111.pradnik.net/addons/busybox2-extended.tar.gz
box# tar xzvf busybox2-extended.tar.gz
...

Make sure you have the /usr/bin (symlink to /mnt/C/sys/bin) in your PATH environment variable.

Download

The script can be downloaded from the Packages section or you can get it from console via wget as follows (of course you have to make it executable via chmod command):

box# cd /mnt/C
box# wget http://filodej.ic.cz/filopack/filopack.sh
box# chmod 755 filopack.sh

Usage

Now we have the script ready to be used. When we start it with no arguments it just prints the command line documentation. It covers "basic" usage which is suitable for most users.

box# ./filopack.sh
Stupid packaging system (version 0.3.6)

Usage:
 
  filopack.sh [OPTIONS] [<action>] [<package-name>]

Basic usage:

  Basic actions: 
    (typically used when you just download and install/uninstall pre-built packages)

    --help     ... prints detailed help message
    --version  ... prints version of the script
    --config   ... perform system (re)configuration
    --packages ... lists all packages available for download
    --download ... downloads a selected package
    --print    ... just prints the files of selected package
    --install  ... unpacks (installs) the package  
    --delete   ... deletes the given package archive
    --remove   ... removes (uninstalls) the package
    --summary  ... generates a summary of installed packages

In case one wants to create own packages or perform remote package installation there is also the "advanced" mode supported. I'll come back to this mode later.

Initial configuration

Now we have to configure the package destination directory (/mnt/C by default) as well as box IP/hostname and username. Latter two parameters are used just for remote packaging and so "basic" users can simply ignere it and leave the default values. With --config action we can re-configure system any time later.

box# ./filopack.sh --config
Destination address and user not configured (.filopack/.config file not found)
Insert destination directory [/mnt/C]: 
Insert box IP address or hostname (remote packaging only)[storage]: 
Insert box user account (remote packaging only) [root]: 
Settings stored to .filopack/.config file

Package listing

Now we are ready to retrieve the list of available packages. Individual package names are used as identifiers for package installation/uninstallation.

box# ./filopack.h --packages
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Available packages:
Mesa-7.0.3
MesaDemos-7.0.3
atk-1.22.0
audiofile-0.2.6
binutils-2.18
boost-1.35.0
cairo-1.6.4
code2html-0.9.1
cvstrac-2.0.1-3
dbus-1.2.1
dbus-glib-0.76
dbus-python-0.82.4
deluge-0.9.03
didiwiki-0.5
faad2-2.6.1
file-4.24
flac-1.2.1
fontconfig-2.6.0
gcc-4.1.2-sjlj
git-1.5.5.3
glade3-3.4.5
glib-2.17.2
gperf-3.0.3
gtk+-2.13.3
highlight-2.6.10
htop-0.8
httpd-2.2.8
jasper-1.701.0-2
jpeg-6b
libao-0.8.8
libglade-2.6.2
libid3tag-0.15.1b
libmikmod-3.2.0-beta2
libogg-1.1.3
libvorbis-1.2.0
libxcb-1.1
libxml2-2.6.30
libxslt-1.1.22
lsof-4.78
mod_python-3.3.1
mpd-0.13.2
pango-1.21.3
pycairo-1.4.12
pygobject-2.14.2
pygtk-2.12.1
python-2.5.2
pyxdg-0.15
source-highlight-1.9
sqlite-3.5.8
strace-4.5.15
streamripper-1.63.1
subversion-1.5.0
tiff-3.8.2
x11-7.1
xcb-util-0.2

Package retrieval

Let's say we are interested in the htop-0.8 package and we want to learn the contents.

box# ./filopack.sh --print htop-0.8
.filopack/htop-0.8.lst: No such file or directory

Unfortunately in this version we have to download the whole package in order to learn the contents (Maybe it will be changed in a future version).
We can use the following action in order to download the package:

box# ./filopack.sh --download htop-08 
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Package htop-08 not available (try to use --packages switch)

Once more, now with the correct package name:

box# ./filopack.sh --download htop-0.8
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package htop-0.8 from http://filodej.ic.cz ...
connected!

Length: 102 [text/plain]
connected!

Length: 224,259 [application/x-gtar]

Now we are ready to print the package contents:

box# ./filopack.sh --print htop-0.8
sys/bin/htop
sys/share/man/man1/htop.1
sys/share/applications/htop.desktop
sys/share/pixmaps/htop.png

Package installation

box# ./filopack.sh --install htop-0.8
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Sure to unpack htop-0.8 locally at /mnt/C (y/n)?y
sys/bin/htop
sys/share/man/man1/htop.1
sys/share/applications/htop.desktop
sys/share/pixmaps/htop.png

Now if you want to spare some disk space, you can delete the package archive file:

box# ./filopack.sh --delete htop-0.8 
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Are you sure to delete the htop-0.8.tgz archive (y/n)?y

Package removal

If later on you change your mind and decide to remove the package, you can do it as follows:

box# ./filopack.sh --remove htop-0.8
Configuration file .filopack/.config file found and used
Sure to remove htop-0.8 locally at /mnt/C (y/n)?y

... and now if you try to uninstall the same package again, operation fails (since there are no such files).

box# ./filopack.sh --remove htop-0.8
Configuration file .filopack/.config file found and used
Sure to remove htop-0.8 locally at /mnt/C (y/n)?y
rm: cannot remove `sys/bin/htop': No such file or directory
rm: cannot remove `sys/share/man/man1/htop.1': No such file or directory
rm: cannot remove `sys/share/applications/htop.desktop': No such file or directory
rm: cannot remove `sys/share/pixmaps/htop.png': No such file or directory

You may also want to get a summary what packages are available and what package archives are downloaded and/or installed.

Package summary

box# ./filopack.sh --summary
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)

Filodej package summary:
Package name                          downloaded [#installed/#total]
--------------------------------------------------------------------
Mesa-7.0.3                               yes           [  49/  49]
MesaDemos-7.0.3                          yes           [ 129/ 129]
atk-1.22.0-new                           yes           [ 160/ 160]
binutils-2.18-latest                     yes           [ 140/ 140]
boost-1.35.0-gcc4.1.2                    yes           [5195/5195]
boost-1.35                               yes           [5133/5195]
cairo-1.6.4                              yes           [  76/  76]
code2html-0.9.1                          yes           [   2/   2]
cvstrac-2.0.1-3                           no           [   3/   3]
dbus-1.2.1                               yes           [  38/  41]
dbus-glib-0.76                           yes           [  32/  32]
dbus-python-0.82.4                       yes           [  66/  66]
deluge-0.9.03-latest                     yes           [ 651/ 674]
deluge-torrent-0.5.9.3-new               yes           [   0/1543]
deluge-torrent-0.5.9.3                   yes           [   0/  99]
didiwiki-0.5                              no           [   1/   1]
file-4.24                                yes           [  11/  11]
fontconfig-2.6.0                         yes           [ 429/ 429]
gcc-4.1.2-sjlj                           yes           [  99/ 549]
git-1.5.5.3                               no           [ 228/ 228]
glade3-3.4.5                             yes           [ 323/ 323]
glib-2.17.2                              yes           [ 501/ 501]
gperf-3.0.3                              yes           [   4/   4]
gtk+-2.10.14                             yes           [1155/1155]
gtk+-2.13.3                              yes           [1233/1233]
highlight-2.6.10                          no           [ 206/ 206]
htop-0.8                                  no           [   0/   4]
httpd-2.2.8                               no           [ 174/ 174]
jasper-1.701.0-2                         yes           [  27/  27]
jpeg-6b                                  yes           [  10/  10]
libglade-2.6.2                           yes           [  34/  34]
libogg-1.1.3                              no           [  83/  83]
libvorbis-1.2.0                           no           [ 125/ 125]
libxcb-1.1                               yes           [ 160/ 160]
libxml2-2.6.30                           yes           [ 322/ 322]
libxslt-1.1.22                           yes           [ 142/ 142]
lsof-4.78                                yes           [   1/   1]
mod_python-3.3.1                          no           [  26/  26]
pango-1.21.3                             yes           [ 146/ 146]
pycairo-1.4.12                           yes           [   7/   7]
pygobject-2.14.2                         yes           [  44/  44]
pygtk-2.12.1                             yes           [ 647/ 649]
python-2.5.2                             yes           [3648/3648]
pyxdg-0.15                               yes           [  25/  25]
source-highlight-1.9                      no           [  49/  49]
sqlite-3.5.8                              no           [   8/   8]
strace-4.5.15                            yes           [   3/   3]
streamripper-1.63.1                       no           [  13/  13]
subversion-1.4.6-py-pl                    no           [ 211/ 211]
subversion-1.5.0                         yes           [ 319/ 319]
tiff-3.8.2                                no           [ 231/ 231]
x11-7.1                                  yes           [7791/7791]
xcb-util-0.2                              no           [  70/  70]

So that is all for now. In a following post I extend the tutorial with examples of "advanced" usage.

WMU-6500FS - Deluge torrent (part III)

2008-08-06T11:22:00.022+02:00

Overview

In previous part I tried to workaround the issue with uncaught exceptions (due to the GCC mis-configuration), but after the long effort (and after a discovery of a separate linker problem) I decided to rebuild the GCC compiler.
Now with the new (properly configured) compiler we are ready to finish the deluge build process and finish the installation.
In this post there are described new possibilities how to use the new version of the deluge torrent client, for me especially attractive is the "daemon" mode.

Build result

[file list]

Screenshots

Deluge daemon and GTK client both running on WMU-6500fs box
GTK and web client running on Ubuntu
GTK and web client running on Windows XP

Info sources:

[Deluge News] [Deluge FAQ]

Build sequence:

dev# cd /usr/local/src/deluge-0.9.03
dev# python setup.py clean
dev# python setup.py build
dev# python setup.py install --prefix=/mnt/C/sys/

Now, when we test the new instalation, there is another problem with exception handling:

dev# deluge
[INFO    ] 00:13:19 main:84 Deluge ui 0.9.03
...
[DEBUG   ] 00:13:23 configmanager:88 Getting config 'gtkui.conf'
can't resolve symbol '_Unwind_Resume_or_Rethrow' 4.1.2

With the deluge daemon the problem is the same:

dev# deluged
can't resolve symbol _Unwind_Resume_or_Rethrow' 4.1.2

It seems there are missing symbols for the exception unwinding. Let's look at the libtorrent dependencies:

dev# cd /usr/local/src/deluge-0.9.03
dev# ldd build/lib.linux-i686-2.5/deluge/libtorrent.so
        libboost_filesystem-gcc33-mt-1_35.so.1.35.0 => /mnt/C/sys/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_date_time-gcc33-mt-1_35.so.1.35.0 => /mnt/C/sys/lib/libboost_date_time-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_iostreams-gcc33-mt-1_35.so.1.35.0 => /mnt/C/sys/lib/libboost_iostreams-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_python-gcc33-mt-1_35.so.1.35.0 => /mnt/C/sys/lib/libboost_python-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_thread-gcc33-mt-1_35.so.1.35.0 => /mnt/C/sys/lib/libboost_thread-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
        libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x00000000)
        libz.so.1 => /lib/libz.so.1 (0x00000000)
        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x00000000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000)
        libc.so.0 => /lib/libc.so.0 (0x00000000)
        libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00000000)
        libdl.so.0 => /lib/libdl.so.0 (0x00000000)
        libutil.so.0 => /lib/libutil.so.0 (0x00000000)
        libm.so.0 => /lib/libm.so.0 (0x00000000)
        /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)

And now when we look at the individual symbol dependencies:

dev# nm -D build/lib.linux-i686-2.5/deluge/libtorrent.so | grep Unwind
         U _Unwind_SjLj_Register
         U _Unwind_SjLj_Resume
         U _Unwind_SjLj_Unregister

dev# nm -D /mnt/C/sys/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0 | grep Unwind
         U _Unwind_Register
         U _Unwind_Resume
         U _Unwind_Unregister

... It is clear that I forgot to rebuild the boost library with the new compiler!
Ok, so let's fix it and not forget to activate back the exceptions (comment out the define we previously added to the boost/config/user.hpp):

dev# cd ../boost_1_35_0
dev# nano boost/config/user.hpp

    //#define BOOST_NO_EXCEPTIONS
dev# ./configure --prefix=/mnt/C/sys/
dev# make
...patience...
...found 3940 targets...
...updating 9 targets...
...
...updated 9 targets...

dev# make install
...found 14676 targets...
...updating 7 targets...
...
...updated 7 targets...

Now let's go back to deluge and rebuild it:

dev# cd ../deluge-0.9.03
dev# python setup.py clean
dev# python setup.py build
...
/mnt/C/sys/lib/gcc/i386-linux-uclibc/4.1.2/../../../../i386-linux-uclibc/bin/ld: cannot find -lboost_filesystem
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

We have to update the symlinks we previously created for gcc33 version of boost libraries:

dev# cd /mnt/C/sys/lib
dev# for i in `ls ./libboost_*-gcc41-mt-1_35.so.1.35.0`; do ln -s $i ${i/%-gcc41-mt-1_35.so.1.35.0/.so}; done
`./libboost_date_time.so': File exists
...
`./libboost_wave.so': File exists

The links are already there, but we want to rewrite them:

dev# ls -l libboost_date_time.so
lrwxrwxrwx  1 root root 44 Jul 23 06:33 libboost_date_time.so -> ./libboost_date_time-gcc33-mt-1_35.so.1.35.0
dev# for i in `ls ./libboost_*-gcc41-mt-1_35.so.1.35.0`; do ln --force -s $i ${i/%-gcc41-mt-1_35.so.1.35.0/.so}; done

Now we can proceed with deluge:

dev# cd /usr/local/src/deluge-0.9.03
dev# python setup.py build 
dev# python setup.py install --prefix=/mnt/C/sys

Ok, it is now installed. When we try it we end up with already known icon issue (sed helps us to solve it):

dev# deluge
...
 line 59, in __init__
    self.dialog.set_icon(deluge.common.get_logo(32))
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-0.9.03-py2.5-linux-i686.egg/deluge/common.py", line 143, in get_logo
    size, size)
gobject.GError: Unrecognized image file format
dev# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/lib/python2.5/site-packages/deluge-0.9.03-py2.5-linux-i686.egg/deluge/common.py

Next run ended up with segfault:

dev# deluge
...
gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed
  self.window.show()
Segmentation fault

In order to be able to debug it, I had to deploy it to the box. But after the deployment some more problems emerged:

box# deluge
Traceback (most recent call last):
  File "/usr/bin/deluge", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py", line 2561, in <module>
  File "/usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py", line 626, in require
  File "/usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py", line 524, in resolve
pkg_resources.DistributionNotFound: deluge==0.9.03

... we have to create a path to deluge egg:

box# cd /mnt/C/sys/lib/python2.5/site-packages
box# echo "./deluge-0.9.03-py2.5-linux-i686.egg" > deluge.pth

Then I noticed following wierd error:

box# deluge
...
gobject.GError: Failed to open file 

'/tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-0.9.03-py2.5-linux-i686.egg/deluge/data/pixmaps/seeding16.png': No such file or directory

... do not know why, two files were untarred with a wrong name (with "0000644" postfix), quick fix:

box# mv /tmp/mnt/C/sys/lib/python2.5/site-packages/deluge-0.9.03-py2.5-linux-i686.egg/deluge/data/pixmaps/seeding16.png{0000644,}

... then it seems we successfully replicated the crash:

box# deluge
...
rning: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed
  self.window.show()
Segmentation fault

Let's start debugging:

box# gdbserver colinux:2345 `which python` `which deluge`

... and attach with debugger remotely:

dev# gdb `which python`
...
(gdb) target remote storage:2345
(gdb) cont
Continuing.
[New Thread 1024]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024]
0x408c1572 in render_icon_name_pixbuf () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
(gdb) where
#0  0x408c1572 in render_icon_name_pixbuf () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
#1  0x408c1736 in find_and_render_icon_source () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
#2  0x408c1992 in gtk_icon_set_render_icon () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
#3  0x40a61ded in gtk_widget_render_icon () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
#4  0x408e0499 in gtk_image_calc_size () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
#5  0x408e061e in gtk_image_size_request () from /mnt/C/sys/X11/lib/libgtk-x11-2.0.so.0
...

Do not know why the exactly render_icon_name_pixbuf function crashed, but I noticed that I was not running the Xming server, when I started it, the problem was gone.
Another problem - missing __cxa_pure_virtual symbol:

box# deluged
/usr/bin/python: can't resolve symbol '__cxa_pure_virtual'

... was "solved" with dirty LD_PRELOAD workaround, then there was another missing symbol 'BIO_free':

box# LD_PRELOAD=/usr/lib/libstdc++.so.6 deluged
/usr/bin/python: can't resolve symbol BIO_free

... pre-loading libssl moved us forward to next missing symbol '_ZN5boost6system18get_posix_categoryEv':

box# LD_PRELOAD="/usr/lib/libstdc++.so.6 /usr/lib/libssl.so.0.9.7" deluged
/usr/bin/python: can't resolve symbol _ZN5boost6system18get_posix_categoryEv

Have no idea what exactly is going on here (and would be pleased if anybody described it to me), but as a workaround the following helped:

box# LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" deluged

The same pair of libraries I am pre-loading for the deluge GUI.

Setup

Finally I was able to run deluge, but yet, I forgot to create symlinks to font directories:
For details see this page.

box# mkdir /usr/share/fonts
box# ln -sn /mnt/C/sys/X11/lib/X11/fonts/OTF /usr/share/fonts/X11-OTF
box# ln -sn /mnt/C/sys/X11/lib/X11/fonts/TTF /usr/share/fonts/X11-TTF

The next thing I set up was to allow remote connections: Then on client machines - running Win XP and Ubuntu in my case - in order to be able to remotely connect to the deluge daemon running on the WMU-6500fs box - I had to disable the classic mode: ... and select storage as a default host in Connection Manager: As can be seen at following screenshot, the memory consumption is relatively high, but when I am not running web gui on the box (just deluged daemon) and am connecting to it from other computers, it is very stable and running smoothly.

WMU-6500FS - gcc 4.1.2

2008-08-06T00:19:00.004+02:00

Overview

During the deluge build I tried to workaround the issue with uncaught exceptions (due to the GCC mis-configuration), but after the long effort (and after a discovery of a linker problem) I decided to rebuild GCC compiler.

Rationalization

This discussion contains a simple test for exception catching. So we can get the two simple programs and test whether the exceptions are handled properly:

dev# cd /usr/local/src/
dev# mkdir test_exceptions
dev# cd test_exceptions/
dev# wget http://codepoet.org/throw1.cpp
dev# wget http://codepoet.org/throw2.cpp
dev# g++ -Wall -O2 throw1.cpp -o throw1
dev# ./throw1
Aborted

With the current compiler (gcc version 3.3.6 configured without --enable-sjlj-exceptions flag) the exceptions are not caught at all. This message named "libgcc_s.so compatibility between 3.3 and 3.4 (sjlj/dwarf2 exceptions)" describes a problem with the change of default exception model and it is likely that this issue applies exactly in our case.

What version?

When we are re-building the compiler, why not to upgrade to a newer version? Based on uClibc FAQ I choose the version 4.1.2 (along with binutils version 2.18):

The last two GNU binutils releases are 2.17 and 2.18. While 2.16 should work, workarounds for bugs in it are not considered. Since the GCC-3.4 and GCC-4.1 series are the recent stable release series (since the 4.0 and 4.2 series tend to be a bit broken for everyone), they are the latest versions we will address. If you encounter a compile error using an older version (say GCC 3.2), then you're out of luck. You'll need to workaround it yourself.

binutils-2.18

Building this package was the easy part:
Build results: [binary] [files list]

Build sequence:

dev# cd /usr/local/src
dev# wget http://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2
dev# tar xjvf binutils-2.18.tar.bz2
dev# cd binutils-2.18
dev# ./configure --host=i386-linux-uclibc --target=i386-linux-uclibc --build=i386-pc-linux-uclibc --prefix=/mnt/C/sys
dev# ./make
dev# make install

gcc 4.1.2

Info sources: [Prerequisites] [How to configure] [How to build]
Build results: [binary] [files list]

Build sequence:
We can either download whole source package:

dev# cd /usr/local/src
dev# wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.1.2/gcc-4.1.2.tar.bz2
dev# tar xjvf gcc-4.1.2.tar.bz2
dev# cd gcc-4.1.2/

... or we can pick out just packages we are interested in - for example:

dev# cd /usr/local/src
dev# wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.1.2/gcc-core-4.1.2.tar.bz2
dev# tar xjvf gcc-core-4.1.2.tar.bz2
dev# wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.1.2/gcc-g++-4.1.2.tar.bz2
dev# tar xjvf gcc-g++-4.1.2.tar.bz2
dev# wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.1.2/gcc-objc-4.1.2.tar.bz2
dev# tar xjvf gcc-objc-4.1.2.tar.bz2
dev# wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.1.2/gcc-testsuite-4.1.2.tar.bz2
dev# tar xjvf gcc-testsuite-4.1.2.tar.bz2
dev# cd gcc-4.1.2/

Now we can try to configure it:

dev# ./configure --prefix=/mnt/C/sys --host=i386-linux-uclibc --target=i386-linux-uclibc --build=i386-pc-linux-uclibc 
--enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls 
--enable-multilib --with-x --x-includes=/mnt/C/sys/X11/include/ --x-libraries=/mnt/C/sys/X11/lib/ 
--with-gxx-include-dir=/usr/include/c++ --enable-bootstrap 
...
checking for MPFR... no
*** This configuration is not supported in the following subdirectories:
     target-libada gnattools target-libgfortran target-libffi target-boehm-gc 
     target-zlib target-libjava zlib fastjar target-libobjc
    (Any other directories should still work fine.)

The MPFR library is a C library for multiple-precision floating-point computations with correct rounding.

For now I decided to proceed without it:

dev# make
...
/usr/local/src/gcc-4.1.2/host-i386-linux-uclibc/prev-gcc/xgcc 
-B/usr/local/src/gcc-4.1.2/host-i386-linux-uclibc/prev-gcc/ -B/mnt/C/sys/i386-linux-uclibc/bin/   
-O2 -g -fomit-frame-pointer -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute 
-Werror    -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o build/errors.o ../../build-i386-pc-linux-uclibc/libiberty/libiberty.a
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
make[3]: *** [s-modes] Error 127

This problem emerged after the long portion of the build process, in stage 2. When we try to launch genmodes from the stage 1 (built with the "old" gcc) it runs with no problem:

dev# ./host-i386-linux-uclibc/stage1-gcc/build/genmodes
...
DOUBLE ? &ieee_extended_intel_96_round_53_format : &ieee_extended_intel_96_format);
}

But the one from stage 2 (built with a new gcc) does not run at all:

dev# ./host-i386-linux-uclibc/stage2-gcc/build/genmodes
-sh: ./host-i386-linux-uclibc/stage2-gcc/build/genmodes: No such file or directory

In this message somebody is dealing with similar problem - In such cases it seems there is wrong path to the loader hardcoded in the generated elf file.
So let's inspect the executables with readelf tool (we are mainly interested in used dynamic loader aka interpreter):

dev# readelf -a ./host-i386-linux-uclibc/stage1-gcc/build/genmodes | grep interpreter
      [Requesting program interpreter: /lib/ld-uClibc.so.0]
dev# readelf -a ./host-i386-linux-uclibc/stage2-gcc/build/genmodes | grep interpreter
      [Requesting program interpreter: /lib/ld-linux.so.2]

So now we see the root of the problem. Now how to solve it... I found that there is the loader path hardcoded in gcc/config/linux.h (it does not depend on --target configuration) as follows:

#define DYNAMIC_LINKER "/lib/ld-linux.so.2"

... so it seems we need a patch to correct this (and and possibly other settings) specific to the build in uClibc environment.
After some Web browsing I have found such set of patches here (the patches are actually for gcc-4.1.0, to overcome it we use -p1 patch option instead of -p1):

dev# cd /usr/local/src/gcc-4.1.2
dev# wget -O 100-uclibc-conf.patch "http://dev.wireless-fr.org/browser/firmware/trunk/kamikaze/toolchain/gcc/patches/4.1.2/100-uclibc-conf.patch?rev=353&format=raw"
dev# patch -p1 < 100-uclibc-conf.patch

... now try to continue and after long time we end up with another kind of problem, missing locale support in uClibc:

dev# make
...
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c ../../.././libstdc++-v3/src/ctype.cc  -fPIC -DPIC -o .libs/ctype.o
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h: In static member function 'static const short unsigned int* std::ctype<char>::classic_table()':
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:51: error: '__ctype_b' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h: In constructor 'std::ctype<char>::ctype(int*, const short unsigned int*, bool, size_t)':
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:85: error: '__ctype_toupper' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:86: error: '__ctype_tolower' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:87: error: '__ctype_b' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h: In constructor 'std::ctype<char>::ctype(const short unsigned int*, bool, size_t)':
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:120: error: '__ctype_toupper' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:121: error: '__ctype_tolower' was not declared in this scope
/usr/local/src/gcc-4.1.2/i386-linux-uclibc/libstdc++-v3/include/i386-linux-uclibc/bits/ctype_noninline.h:122: error: '__ctype_b' was not declared in this scope
make[4]: *** [ctype.lo] Error 1
...

For this there is another patch we can apply:

dev# cd /usr/local/src/gcc-4.1.2
dev# wget -O 200-uclibc-locale.patch "http://dev.wireless-fr.org/browser/firmware/trunk/kamikaze/toolchain/gcc/patches/4.1.2/200-uclibc-locale.patch?rev=353&format=raw"
dev# patch -p1 < 200-uclibc-locale.patch

After that I was able to finish build and installation successfully:

dev# make
dev# make install
dev# gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
...

Ok, let's test the new compiler with our simple exception test:

dev# cd /usr/local/src/test_exceptions/
dev# g++ -Wall -O2 throw1.cpp -o throw1
/mnt/C/sys/lib/gcc/i386-linux-uclibc/4.1.2/../../../../i386-linux-uclibc/lib/libstdc++.so: 
  undefined reference to `___tls_get_addr'
collect2: ld returned 1 exit status

According to ldd it seems there are no missing library dependencies:

dev# ldd /mnt/C/sys/lib/gcc/i386-linux-uclibc/4.1.2/../../../../i386-linux-uclibc/lib/libstdc++.so
  libm.so.0 => /lib/libm.so.0 (0x00000000)
  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000)
  libc.so.0 => /lib/libc.so.0 (0x00000000)
  /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)

Following message contains some info about this issue. According to this message there should be no tls problem after applying all the patches, so maybe the correct solution is to download all remaining patches from this site. There is one patch dealing with libstdc++, but I am not sure whether it solves the TLS problem.
At the time I decided to re-configure GCC regarding to advice in this message:

dev# cd /usr/local/src/gcc-4.1.2
dev# make distclean
dev# ./configure --prefix=/mnt/C/sys --host=i386-linux-uclibc --target=i386-linux-uclibc 
--build=i386-pc-linux-uclibc --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit 
--enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib --with-x 
--x-includes=/mnt/C/sys/X11/include/ --x-libraries=/mnt/C/sys/X11/lib/ 
--with-gxx-include-dir=/usr/include/c++ --enable-bootstrap --disable-tls
dev# make
dev# make install

Now let's repeat the test:

dev# cd /usr/local/src/test_exceptions/
dev# g++ -Wall -O2 throw1.cpp -o throw1
dev# ./throw1
Aborted

It seem that exceptions are still not being caught, let's debug it just to make sure:

dev# gdb throw1
GNU gdb 6.3
...
(gdb) run
Starting program: /usr/local/src/test_exceptions/throw1

Program received signal SIGABRT, Aborted.
0xb7e63164 in kill () from /lib/libc.so.0

(gdb) where
#0  0xb7e63164 in kill () from /lib/libc.so.0
#1  0xb7e5345a in raise () from /lib/libc.so.0
#2  0xb7e5cc67 in abort () from /lib/libc.so.0
#3  0xb7eb82f8 in uw_init_context_1 (context=0xbf83b150, outer_cfa=0xbf83b1d0, outer_ra=0xb7f5fb08)
    at ../.././gcc/unwind-dw2.c:1255
#4  0xb7eb86d4 in _Unwind_RaiseException (exc=0x804ab68) at unwind.inc:92
#5  0xb7f5fb08 in __cxa_throw (obj=0x804ab88, tinfo=0x80499e0, dest=0)
    at ../../.././libstdc++-v3/libsupc++/eh_throw.cc:72
#6  0x08048737 in main ()

(gdb) list
67        header->unwindHeader.exception_cleanup = __gxx_exception_cleanup;
68
69      #ifdef _GLIBCXX_SJLJ_EXCEPTIONS
70        _Unwind_SjLj_RaiseException (&header->unwindHeader);
71      #else
72        _Unwind_RaiseException (&header->unwindHeader);
73      #endif
74
75        // Some sort of unwinding error.  Note that terminate is a handler.
76        __cxa_begin_catch (&header->unwindHeader);

So it seems there are still two versions of exception handling and the one without SjLj does not work even with the new gcc version. I do not know exactly what is going on here, initially I thoought that the exception problem is specific to the 3.3 - 3.4 gcc versions, but regarding to this message it is possible that in some scenarios the --enable-sjlj-exceptions configuration is necessary for 4.x versions as well:

I have rebuilt gcc-3.4.4 w/ sjlj-exceptions, both the uclibc++ test and and throw2 perform ok against libstdc++ and uclibc++, so up to 3.4.4 (but probably 4.0.0 too) need --enable-sjlj-exceptions

So let's try to re-configure the build once more:

dev# cd /usr/local/src/gcc-4.1.2
dev# make distclean
dev# ./configure --prefix=/mnt/C/sys --host=i386-linux-uclibc --target=i386-linux-uclibc 
--build=i386-pc-linux-uclibc --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit 
--enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib --with-x 
--x-includes=/mnt/C/sys/X11/include/ --x-libraries=/mnt/C/sys/X11/lib/ 
--with-gxx-include-dir=/usr/include/c++ --enable-bootstrap --disable-tls --enable-sjlj-exceptions
dev# make
dev# make install

And now when we repeat the test:

dev# cd /usr/local/src/test_exceptions/
dev# g++ -Wall -O2 throw1.cpp -o throw1
dev# ./throw1
caught an exception

Hurray! It seems now we have some progress.
Let's try the second one:

dev# g++ -Wall -O2 throw2.cpp -o throw2
dev# ./throw2
1  Throwing out_of_range()
    Catching: out_of_range out_of_range meaningful comment
2  Throwing exception()   // Can't specify comment
    Catching: St9exception
3  Throwing underflow_error  // caught by base class (runtime_error)
    Catching: runtime_error underflow_error
4  Throwing runtime_error
    Catching: runtime_error a comment
5  Throwing length_error   // caught be super-super-class (exception)
    Catching: St9exception
6  Throwing int
    Catching: int 26
7  Throwing const char*
    Catching: const char* This is a const char*
8  Throwing string
    Catching: string I'm a string
9  Throwing float
    ERROR: Nobody caught this!
10  Throwing up

The exception #9 is not caught but regarding to this discussion it seems ok.
Now we have the gcc version 4.1.2 properly configured, built and ready for building c++ applications like deluge.

WMU-6500FS - strace 4.5.15

2008-07-28T14:24:00.005+02:00

strace is a system call tracer, i.e. a debugging tool which prints out a trace of all the system calls made by a another process/program.
Build result: [binary] [files list]

Info sources: [Man page] [Project page]

Build sequence:

dev# wget "http://downloads.sourceforge.net/strace/strace-4.5.15.tar.bz2?modtime=1168972008&big_mirror=0&filesize=455607"
dev# tar xjvf strace-4.5.15.tar.bz2
dev# cd strace-4.5.15
dev# ./configure --prefix=/mnt/C/sys
dev# make
cdv# make install

WMU-6500FS - Deluge torrent (part II)

2008-07-26T01:22:00.015+02:00

Overview

In previous part we have started building the deluge torrent ...

We ended up with a curious error, process was aborted after an exception thrown in libtorrent::bdecode. It seems that for some reason there is exception thrown and not caught which causes immediate process termination.

Screenshot

Here is a screenshot of the remote debugging in action:

Uncaught exception

When we look at the strace output:

...
close(11)                               = 0
write(1, "Applying preferences\n", 21Applying preferences
)  = 21
write(1, "Starting DHT...\n", 16Starting DHT...
)       = 16
open("/root/.config/deluge/dht.state", O_RDONLY) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(31503, SIGABRT)                    = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
Process 31503 detached

Call stack at the moment of termination:

...
Program received signal SIG32, Real-time event 32.
0x4019cb64 in __rt_sigsuspend () from /lib/libc.so.0
(gdb) Quit
(gdb) where
#0  0x4019cb64 in __rt_sigsuspend () from /lib/libc.so.0
#1  0x4019cb9b in sigsuspend () from /lib/libc.so.0
#2  0x40139cf9 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#3  0x401396bd in pthread_create () from /lib/libpthread.so.0
#4  0x416c9f26 in boost::thread::start_thread () from /mnt/C/sys/lib//libboost_thread-gcc33-mt-1_35.so.1.35.0
#5  0x415d68c8 in disk_io_thread (this=0x821acc8, block_size=-4) at thread.hpp:151
...

An the corresponding source file src/deluge_core.cpp

    boost::filesystem::path tempPath(DHT_path, empty_name_check);
    boost::filesystem::ifstream DHT_state_file(tempPath, std::ios_base::binary);
    DHT_state_file.unsetf(std::ios_base::skipws);

    entry DHT_state;
    try
    {
(1)     DHT_state = bdecode(std::istream_iterator<char>(DHT_state_file),
            std::istream_iterator<char>());
        M_ses->start_dht(DHT_state);
        //        printf("DHT state recovered.\r\n");

        //        // Print out the state data from the FILE (not the session!)
        //        printf("Number of DHT peers in recovered state: %ld\r\n", count_DHT_peers(DHT_state));

    }
(2) catch (std::exception&)
    {
        printf("No DHT file to resume\r\n");
        M_ses->start_dht();
    }

... it seems obvious what happened. Application tried to open the dht.state file and since there was no such file an exception was thrown in the std::istream_iterator constructor (source code line marked as (1)). This exception is nevertheless not caught in the catch block (source code line marked as (2)). I do not know why, there is no aparent reason (the exception has definitely the std::exception base), the fact is that due to this the application is aborted.

Uncaught exception - workaround

For now I decided to make the following workaround, explicitly handle the missing file and so bypass the exception:

    boost::filesystem::path tempPath(DHT_path, empty_name_check);
    boost::filesystem::ifstream DHT_state_file(tempPath, std::ios_base::binary);
    DHT_state_file.unsetf(std::ios_base::skipws);

    entry DHT_state;
    if ( !exists( tempPath ) )
    {
        printf("No DHT file to resume\r\n");
        M_ses->start_dht();
    }
    else try
    {
        DHT_state = bdecode(std::istream_iterator<char>(DHT_state_file),
            std::istream_iterator<char>());
        M_ses->start_dht(DHT_state);
        //        printf("DHT state recovered.\r\n");

        //        // Print out the state data from the FILE (not the session!)
        //        printf("Number of DHT peers in recovered state: %ld\r\n", count_DHT_peers(DHT_state));

    }
    catch (std::exception&)
    {
        printf("No DHT file to resume\r\n");
        M_ses->start_dht();
    }

The unified diff looks as follows:

dev# diff -u src/deluge_core.cpp.old src/deluge_core.cpp
--- src/deluge_core.cpp.old     2008-06-04 20:03:49.000000000 -0600
+++ src/deluge_core.cpp 2008-07-02 16:32:01.000000000 -0600
@@ -1889,7 +1889,12 @@
     DHT_state_file.unsetf(std::ios_base::skipws);

     entry DHT_state;
-    try
+    if ( !exists( tempPath ) )
+    {
+        printf("No DHT file to resume\r\n");
+        M_ses->start_dht();
+    }
+    else try
     {
         DHT_state = bdecode(std::istream_iterator<char>(DHT_state_file),
             std::istream_iterator<char>());

With this workaround we are able to sucessfully open the application. But when we add a torrent file, there is another (but similar) problem. Another exception is thrown which leads to process termination. Since the local debugging is really slow on the box, before we proceed to solve this problem, let's look how to debug remotely.

Remote debugging

For remote debugging we will use the gdbserver. Following relevant inf is in the GDB remote debugging manual:

gdbserver is a control program for Unix-like systems, which allows you to connect your program 
with a remote GDB via target remote - but without linking in the usual debugging stub.
...
The `host:2345' argument means that gdbserver is to expect a TCP connection from machine `host' 
to local TCP port 2345. (Currently, the `host' part is ignored.)
...
On some targets, gdbserver can also attach to running programs. This is accomplished via the 
--attach argument.
...
On the GDB host machine, you need an unstripped copy of your program, since GDB needs symbols 
and debugging information. Start up GDB as usual, using the name of the local copy of your 
program as the first argument. ... After that, use target remote to establish communications 
with gdbserver.

The use of gdbserver is ideal for us, since due to the deployment process we have identical copied of the debugged program both on the box# and on the build dev# system.

So on the box we can run the deluge

box# deluge &
[1] 29193

... and attach to it with the gdbserver:

box# gdbserver colinux:2345 --attach 29193
Attached; pid = 29193
Listening on port 2345

or alternatively we can run the gdbserver running the deluge roght from the beggining:

box# gdbserver colinux:2345 `which python` `which deluge`
Process /mnt/C/sys/bin/python created; pid = 29235
Listening on port 2345

Now we can connect to the gdbserver with gdb running on the build machine (PC). Since the deluge just a python script, the executable we will debug is in fact python interpreter:

dev# gdb `which python`
...
(gdb) target remote 192.168.1.104:2345
(gdb) cont
Continuing.
[New Thread 1024]
...

Ok, that's it.

Note: sometimes, when we interrupt the debugging process, the deluge is not properly killed, there remains an instance. When we start deluge again the output looks like this:

...
create proxy object
create iface
send to iface

Child exited with retcode = 0

Child exited with status 0
GDBserver exiting

In such situation we have to find the hanging processes and kill them:

box# ps ax | grep deluge
29429 root      14136 S     1.7  /mnt/C/sys/bin/python /mnt/C/sys/bin/deluge
29440 root      14136 S     0.0  /mnt/C/sys/bin/python /mnt/C/sys/bin/deluge
29482 root        324 S     0.0  grep deluge
box# kill -9 29429 29440

Uncaught exceptions - looking for a cause

So as I already said, the workaround pushed us forward, but another exception is thrown later on, when we open a torrent file:

(gdb) where
...
#81 0xbfffca60 in ?? ()
#82 0x4027140f in __cxa_call_unexpected () from /mnt/C/sys/lib//libstdc++.so.5
#83 0x4027140f in __cxa_call_unexpected () from /mnt/C/sys/lib//libstdc++.so.5
#84 0x40271439 in std::terminate () from /mnt/C/sys/lib//libstdc++.so.5
#85 0x40271560 in __cxa_throw () from /mnt/C/sys/lib//libstdc++.so.5
#86 0x414d0d39 in libtorrent::entry::operator[] (this=0x821a4e0, key=0x41644ef4 "url-list") at entry.hpp:77
#87 0x415a5bc8 in libtorrent::torrent_info::read_torrent_info (this=0xbfffd090, torrent_file=@0xbfffcee0)
    at libtorrent/src/torrent_info.cpp:519
#88 0x4159e59e in torrent_info (this=0xbfffd090, torrent_file=@0xbfffcee0) at libtorrent/src/torrent_info.cpp:236
#89 0x41629068 in internal_get_torrent_info (torrent_name=@0x6) at src/deluge_core.cpp:264
#90 0x4162d0e7 in torrent_dump_file_info (self=0x0, args=0x41a7ab2c) at stl_alloc.h:652
#91 0x4005d122 in PyCFunction_Call (func=0x4127122c, arg=0x41a7ab2c, kw=0x6) at Objects/methodobject.c:108
...

When we look at the stack frame 87 and torrent_file structure:

(gdb) frame 87
#87 0x415a5bc8 in libtorrent::torrent_info::read_torrent_info (this=0xbfffd090, torrent_file=@0xbfffcee0)
    at libtorrent/src/torrent_info.cpp:519
519                             entry const& url_seeds = torrent_file["url-list"];

(gdb) list
514                     catch (type_error) {}
515
516                     // if there are any url-seeds, extract them
517                     try
518                     {
519                             entry const& url_seeds = torrent_file["url-list"];
520                             if (url_seeds.type() == entry::string_t)
521                             {
522                                     m_url_seeds.push_back(url_seeds.string());
523                             }

(gdb) print torrent_file
$1 = (const libtorrent::entry &) @0xbfffcee0: {m_type = dictionary_t, {data = "øv!\b\004\000\000\000ògB@",
    dummy_aligner = 17316280056}}

... and to the src/deluge-torrent-0.5.9.3/libtorrent/src/entry.cpp file :

#ifndef BOOST_NO_EXCEPTIONS
        const entry& entry::operator[](char const* key) const
        {
                dictionary_type::const_iterator i = dict().find(key);
                if (i == dict().end()) throw type_error(
                        (std::string("key not found: ") + key).c_str());
                return i->second;
        }

        const entry& entry::operator[](std::string const& key) const
        {
                return (*this)[key.c_str()];
        }
#endif

... we can see that the torrent_file is a python-like dictionary, when one tries to access a value stored with a key and there is no such entry, an exception is thrown. As in previous case neither this exception is not caught. It is time to stop with workarounds and look at the exception issue in a finer detail.
This discussion contains an ellegant test for exception catching. It seems that I am not alone having this sort of problems:

> So, the throw+catch are not hooking up properly under uClibc.
> This is uClibc's problem.

What version of uClibc?  gcc?  binutils?  How did you build your
toolchain?  Was gcc built with --enable-sjlj-exceptions?  What
kernel version are you using?
...
> part3:
> comment on gdb #5: __cxa_throw ()
> >From the backtrace above it looks that somethings goes wrong during stack 
> unwinding - does exception catching work for other C++ programs ?

It does if gcc was built properly...

    http://codepoet.org/throw1.cpp
    http://codepoet.org/throw2.cpp

So let's make the same test:

dev# cd /usr/local/src/
dev# mkdir test_exceptions
dev# cd test_exceptions/
dev# wget http://codepoet.org/throw1.cpp
dev# cat throw1.cpp
#include <features.h>
#include "iostream"
int main(void)
{
    try {
        throw("This is an exception");
    }
    catch (...) {
        std::cout << "caught an exception\n";
    }
    return(0);
}
dev# g++ -Wall -O2 throw1.cpp -o throw1
dev# ldd throw1
        libstdc++.so.5 => /lib/libstdc++.so.5 (0xb7edf000)
        libm.so.0 => /lib/libm.so.0 (0xb7ed1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ec9000)
        libc.so.0 => /lib/libc.so.0 (0xb7e35000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f91000)
dev# ./throw1
Aborted

So even in such a trivial case the exception is not caught and process is aborted.
Now let's look at our gcc configuration:

dev# gcc -v
Using built-in specs.
Configured with: /opt/buildroot/toolchain_build_i386/gcc-3.3.6/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-linux-uclibc 
--target=i386-linux-uclibc --enable-languages=c,c++,objc --enable-shared --with-gxx-include-dir=/usr/include/c++ --disable-__cxa_atexit 
--enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib : 
(reconfigured) /opt/buildroot/toolchain_build_i386/gcc-3.3.6/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-linux-uclibc 
--target=i386-linux-uclibc --enable-languages=c,c++,objc --enable-shared --with-gxx-include-dir=/usr/include/c++ --disable-__cxa_atexit 
--enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib : 
(reconfigured) /home/joker/CR/opt/buildroot/toolchain_build_i386/gcc-3.3.6/configure --prefix=/usr --build=i386-pc-linux-gnu 
--host=i386-linux-uclibc --target=i386-linux-uclibc --enable-languages=c,c++,objc --enable-shared --with-gxx-include-dir=/usr/include/c++ 
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib
Thread model: posix
gcc version 3.3.6

... it seems that it is not configured with --enable-sjlj-exceptions.
This message named "libgcc_s.so compatibility between 3.3 and 3.4 (sjlj/dwarf2 exceptions)" describes a problem with the change of default exception model. It seems that the gcc change management (so versioning) did not go very well at that point:

On m68k-linux and parisc-linux between 3.3 and 3.4 the default exception model changed from sjlj based exceptions to dw2 based exceptions. Unfortunately at this time the soversion number of the shared libgcc was not bumped. ... I didn't look at other architectures, if the distinction is needed as well.

Regarding to this message it seems that re-build of GCC with --enable-sjlj-exceptions could be a solution. The problem is that I have not prepared the uClibc build environment (I just used the one prebuilt by JoKeR) and so have no experience with building the GCC.
I did not want to start such a big task, so I decided to give another shot to a workaround:

Disable exceptions

The code in the src/deluge-torrent-0.5.9.3/libtorrent/src/entry.cpp file inspired me to this workaround:

#ifndef BOOST_NO_EXCEPTIONS
        const entry& entry::operator[](char const* key) const
        {
                dictionary_type::const_iterator i = dict().find(key);
                if (i == dict().end()) throw type_error(
                        (std::string("key not found: ") + key).c_str());
                return i->second;
        }

        const entry& entry::operator[](std::string const& key) const
        {
                return (*this)[key.c_str()];
        }
#endif

It seems that the libtorrent code is prepared for cases when there is no exception support in the platform (as is the case for some embedded systems for example). So why not try to disable the boost exceptions?

dev# cd /usr/local/src/boost_1_35_0
dev# nano boost/config/user.hpp

append the following at the end of the file:

#define BOOST_NO_EXCEPTIONS

... and now re-build the boost libraries:

dev# make
...
libs/serialization/src/xml_woarchive.cpp:58:   instantiated from here
boost/archive/iterators/wchar_from_mb.hpp:119: error: `dataflow_exception'
   undeclared in namespace `boost::archive::iterators'
...
...failed updating 9 targets...
...skipped 2 targets...
Not all Boost libraries built properly.

It seems not all the libraries are compatible with this define, anyway, let's proceed (finish the boost installation and restart the deluge build process):

dev# make install
...
dev# cd ../deluge-torrent-0.5.9.3
dev#  python setup.py clean
dev# python setup.py build
...
libtorrent/src/metadata_transfer.cpp: In member function `virtual bool
   libtorrent::<unnamed>::metadata_peer_plugin::on_extension_handshake(const
   libtorrent::entry&)':
libtorrent/src/metadata_transfer.cpp:275: error: passing `const
   libtorrent::entry' as `this' argument of `libtorrent::entry&
   libtorrent::entry::operator[](const char*)' discards qualifiers
error: command 'gcc' failed with exit status 1

In libtorrent/src/metadata_transfer.cpp there is a following code:

    virtual bool on_extension_handshake(entry const& h)
    {
            entry const& messages = h["m"];
            if (entry const* index = messages.find_key("LT_metadata"))
            {
                    m_message_index = int(index->integer());
                    return true;
            }
            else
            {
                    m_message_index = 0;
                    return false;
            }
    }

... in libtorrent/include/libtorrent/entry.hpp there are following map accessors:

                entry& operator[](char const* key);
                entry& operator[](std::string const& key);
#ifndef BOOST_NO_EXCEPTIONS
                const entry& operator[](char const* key) const;
                const entry& operator[](std::string const& key) const;
#endif
                entry* find_key(char const* key);
                entry const* find_key(char const* key) const;
                entry* find_key(std::string const& key);

the solution was to change the operator[] access to find_key() method call:

    virtual bool on_extension_handshake(entry const& h)
    {
//          entry const& messages = h["m"];
            entry const* messages( h.find_key("m") );
            if ( messages )
            {
                if (entry const* index = messages->find_key("LT_metadata"))
                {
                    m_message_index = int(index->integer());
                    return true;
                }
            }
//          else
            {
                    m_message_index = 0;
                    return false;
            }
    }

There is a lot of such places in the code, it seems that the library support for BOOST_NO_EXCEPTIONS directive is not fully implemented yet:

dev# python setup.py build
...
libtorrent/src/ut_pex.cpp: In member function `virtual bool
   libtorrent::<unnamed>::ut_pex_peer_plugin::on_extension_handshake(const
   libtorrent::entry&)':
libtorrent/src/ut_pex.cpp:201: error: passing `const libtorrent::entry' as
   `this' argument of `libtorrent::entry& libtorrent::entry::operator[](const
   char*)' discards qualifiers
error: command 'gcc' failed with exit status 1

I still did not feel ready to rebuild the GCC. In a desperation I looked to the deluge site and noticed that there is a new version out there - 1.0.0_RC3. It promised a change in my miserable situation.

Deluge new version - Disable exceptions

So let's upgrade:

dev# cd /usr/local/src/
dev# wget http://download.deluge-torrent.org/source/0.9.03/deluge-0.9.03.tar.gz
dev# tar xzvf deluge-0.9.03.tar.gz
dev# cd deluge-0.9.03
dev# python setup.py build
...
In file included from /mnt/C/sys/include/boost-1_35/boost/thread.hpp:17,
                 from libtorrent/include/libtorrent/storage.hpp:44,
                 from libtorrent/include/libtorrent/peer_connection.hpp:63,
                 from libtorrent/src/peer_connection.cpp:41:
/mnt/C/sys/include/boost-1_35/boost/thread/recursive_mutex.hpp:18:2: #error "Boost threads unavailable on this platform"
...

We already have a solution for this:

dev# export CFLAGS="-pthread $CFLAGS "

Then there is another build error:

dev# python setup.py build
...
libtorrent/src/torrent_handle.cpp: In member function `const
   libtorrent::torrent_info& libtorrent::torrent_handle::get_torrent_info()
   const':
libtorrent/src/torrent_handle.cpp:503: error: no matching function for call to
   `libtorrent::torrent_info::torrent_info()'
libtorrent/include/libtorrent/torrent_info.hpp:86: error: candidates are:
   libtorrent::torrent_info::torrent_info(const libtorrent::torrent_info&)
libtorrent/include/libtorrent/torrent_info.hpp:130: error:
   libtorrent::torrent_info::torrent_info(const libtorrent::entry&)
libtorrent/include/libtorrent/torrent_info.hpp:92: error:
   libtorrent::torrent_info::torrent_info(const boost::filesystem::path&)
libtorrent/include/libtorrent/torrent_info.hpp:91: error:
   libtorrent::torrent_info::torrent_info(const char*, int)
libtorrent/include/libtorrent/torrent_info.hpp:90: error:
   libtorrent::torrent_info::torrent_info(const libtorrent::lazy_entry&)
libtorrent/include/libtorrent/torrent_info.hpp:89: error:
   libtorrent::torrent_info::torrent_info(const libtorrent::sha1_hash&)
libtorrent/src/torrent_handle.cpp: In member function `libtorrent::entry
   libtorrent::torrent_handle::write_resume_data() const':
libtorrent/src/torrent_handle.cpp:533: error: return-statement with no value,
   in function declared with a non-void return type
error: command 'gcc' failed with exit status 1

When we look at libtorrent/src/torrent_handle.cpp:

        torrent_info const& torrent_handle::get_torrent_info() const
        {
                INVARIANT_CHECK;
#ifdef BOOST_NO_EXCEPTIONS
                const static torrent_info empty;
#endif
                boost::shared_ptr<torrent> t = m_torrent.lock();
        ...

... it is obvious that there the torrent_info has no default constructor, but in case of defined BOOST_NO_EXCEPTIONS such one is used. So I tried to add one:
libtorrent/include/libtorrent/torrent_info.hpp:

#ifdef BOOST_NO_EXCEPTIONS
 torrent_info();
#endif
    torrent_info(sha1_hash const& info_hash);
    torrent_info(lazy_entry const& torrent_file);
    torrent_info(char const* buffer, int size);
    torrent_info(fs::path const& filename);
    ~torrent_info();

libtorrent/src/torrent_info.cpp:

#ifdef BOOST_NO_EXCEPTIONS
        torrent_info::torrent_info()
                : m_creation_date(pt::second_clock::universal_time())
                , m_multifile(false)
                , m_private(false)
                , m_info_section_size(0)
                , m_piece_hashes(0)
        {}
#endif

Another build error and solution was following:

dev# python setup.py build
...
libtorrent/src/torrent_handle.cpp: In member function `libtorrent::entry
   libtorrent::torrent_handle::write_resume_data() const':
libtorrent/src/torrent_handle.cpp:533: error: return-statement with no value,
   in function declared with a non-void return type
error: command 'gcc' failed with exit status 1

Let's look to the libtorrent/src/torrent_handle.cpp file:

        entry torrent_handle::write_resume_data() const
        {
                INVARIANT_CHECK;

                entry ret(entry::dictionary_t);
                TORRENT_FORWARD(write_resume_data(ret));
                t->filesystem().write_resume_data(ret);

                return ret;
        }

When we look at the definition of the macro in the same file:

#ifdef BOOST_NO_EXCEPTIONS

#define TORRENT_FORWARD(call) \
        boost::shared_ptr<torrent> t = m_torrent.lock(); \
        if (!t) return; \
        session_impl::mutex_t::scoped_lock l(t->session().m_mutex); \
        t->call
...
#else

#define TORRENT_FORWARD(call) \
        boost::shared_ptr<torrent> t = m_torrent.lock(); \
        if (!t) throw_invalid_handle(); \
        session_impl::mutex_t::scoped_lock l(t->session().m_mutex); \
        t->call
...

... we see that this version of macro can be used only in function returning void. The solution is use another variant of the macro:

        TORRENT_FORWARD_RETURN2(write_resume_data(ret), entry() );

Let's proceed:

dev# python setup.py build
...
libtorrent/src/memdebug.cpp:34:22: execinfo.h: No such file or directory
libtorrent/src/memdebug.cpp: In constructor `memdebug::memdebug()':
libtorrent/src/memdebug.cpp:61: error: `__malloc_hook' undeclared (first use
   this function)
libtorrent/src/memdebug.cpp:61: error: (Each undeclared identifier is reported
   only once for each function it appears in.)
libtorrent/src/memdebug.cpp:62: error: `__free_hook' undeclared (first use this
   function)
libtorrent/src/memdebug.cpp: In static member function `static void*
   memdebug::my_malloc_hook(unsigned int, const void*)':
libtorrent/src/memdebug.cpp:133: error: `backtrace' undeclared (first use this
   function)
libtorrent/src/memdebug.cpp:144: error: `backtrace_symbols' undeclared (first
   use this function)
error: command 'gcc' failed with exit status 1

This kind of error is not connected with BOOST_NO_EXCEPTIONS. It is due to the missing backtrace support in uClibc.
Fortunately it seems that the memdebug.cpp is used just for memory debugging (prevention of memory leaks and so), this file is self contained and there are no outside dependencies on this file. Let's try simply disable it (simply undefine or clear the file content):

#if 0
#if defined __linux__ && defined __GNUC__
...
#endif
#endif

Here is another BOOST_NO_EXCEPTIONS related build error:

dev# python setup.py build
...
libtorrent/src/http_connection.cpp:208:   instantiated from here
libtorrent/include/libtorrent/variant_stream.hpp:226: error: no matching
   function for call to `libtorrent::ssl_stream<libtorrent::socket_type>::close
   ()'
libtorrent/include/libtorrent/ssl_stream.hpp:158: error: candidates are: void
   libtorrent::ssl_stream<Stream>::close(boost::system::error_code&) [with
   Stream = libtorrent::socket_type]
error: command 'gcc' failed with exit status 1

As we see in the libtorrent/include/libtorrent/ssl_stream.hpp the ssl_stream class contains two overloads of close() method, the non-parametric one disabled in case there are no exceptions:

#ifndef BOOST_NO_EXCEPTIONS
        void close()
        {
                m_sock.next_layer().close();
        }
#endif

        void close(error_code& ec)
        {
                m_sock.next_layer().close(ec);
        }

In libtorrent/include/libtorrent/variant_stream.hpp there are two kinds of close visitor class: close_visitor (one used with exceptions) and close_visitor (one used with error codes), but the "exception" variant is not disabled, let's try to fix it:

 struct close_visitor_ec
    : boost::static_visitor<>
  {
      close_visitor_ec(error_code& ec_)
        : ec(ec_)
      {}

      template <class T>
      void operator()(T* p) const
      { p->close(ec); }

      void operator()(boost::blank) const {}

      error_code& ec;
  };

#ifndef BOOST_NO_EXCEPTIONS
  struct close_visitor
    : boost::static_visitor<>
  {
      template <class T>
      void operator()(T* p) const
      { p->close(); }

      void operator()(boost::blank) const {}
  };
#endif

When we try to rebuild, we can see the place where the inappropriate visitor is called:

dev# python setup.py build
...
libtorrent/include/libtorrent/variant_stream.hpp:665: error: `close_visitor'
   undeclared in namespace `libtorrent::aux'
error: command 'gcc' failed with exit status 1

We have to somewhat fix the libtorrent/include/libtorrent/variant_stream.hpp. There are basically two possibilities: (a) undefine the non-parametric version or (b)(maybe less correctly) use the error code variant and drop the error_code.
... as a quick fix I decided to use the latter method:

    void close(error_code& ec)
    {
        if (!instantiated()) return;
        boost::apply_visitor(
            aux::close_visitor_ec(ec), m_variant
        );
    }

// #ifndef BOOST_NO_EXCEPTIONS   // (1st - more correct - method)
    void close()
    {
//        if (!instantiated()) return;
//        boost::apply_visitor(aux::close_visitor(), m_variant);
        error_code ec;              // 2nd - simpler - method
        close( ec );
    }
// #endif                        // (1st - more correct - method)

Another build problem (with already known solution) followed - undeclared IPV6_V6ONLY; so I have modified the libtorrent/include/libtorrent/socket.hpp and added the dummy IPV6_V6ONLY definition.

Then there was a bunch of errors with dictionary and lack of non-mutable operator[] access in case of BOOST_NO_EXCEPTIONS (similar to the previous version). I decided to solve it with a helper function called get_subentry_const implementing the missing functionality:
The libtorrent/src/kademlia/dht_tracker.cpp file:

        libtorrent::entry const& get_subentry_const( libtorrent::entry const& e, char const* key )
        {
#ifndef BOOST_NO_EXCEPTIONS
            return e[key];
#else
            libtorrent::entry const* const s( e.find_key( key ) );
            if (!s) throw std::runtime_error("subentry not found");
            return *s;
#endif
        }

This function - in case of missing key - throws the exception - which in turn cause the process termination, the question is whether the missing key in client code is really exceptional or it is used in normal program flow... Alternative would be to return reference to a global empty instance of entry class.

Now the client code has to be modified as follows:

//     std::string const& id = r["id"].string();
       std::string const& id = get_subentry_const( r, "id" ).string();

With all these changes the compilation completed succesfully but I got the following link errors:

dev# python setup.py build
...
`.L7753' referenced in section `.rodata' of build/temp.linux-i686-2.5/./libtorrent/src/create_torrent.o: defined in d
iscarded section `.gnu.linkonce.t._ZN5boost9date_time23gregorian_calendar_baseINS0_19year_month_day_baseINS_9gregoria
n9greg_yearENS3_10greg_monthENS3_8greg_dayEEEmE16end_of_month_dayES4_S5_' of build/temp.linux-i686-2.5/./libtorrent/s
rc/create_torrent.o
`.L7740' referenced in section `.rodata' of build/temp.linux-i686-2.5/./libtorrent/src/create_torrent.o: defined in d
iscarded section `.gnu.linkonce.t._ZN5boost9date_time23gregorian_calendar_baseINS0_19year_month_day_baseINS_9gregoria
n9greg_yearENS3_10greg_monthENS3_8greg_dayEEEmE16end_of_month_dayES4_S5_' of build/temp.linux-i686-2.5/./libtorrent/s
rc/create_torrent.o
...
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

As you can see in this bug report it seems as a known compiler bug.
There was one promising hint in this discussion:

While trying to build some C++ code with g++-3.3.6 we encountered error
messages  similar to those mentioned in earlier comments in this discussion:

  `xxx' referenced in section `.rodata' of somefile.o: defined 
  in discarded section `.gnu.linkonce.t._zzz' of something.o

  ...

We were able to eliminate these error messages and successfuly compile our code
with g++-3.3.6 by using the '-frepo' option in our g++ compiles.

I understand that this may not be the ultimate solution to the bug(s) being
discussed here, but since we ended up here when searching for this particular
error message, I'm adding this comment in case it helps other people.

Nevertheless when I tried the suggested workaround:

dev# export CFLAGS="$CFLAGS -frepo"

... the result was exactly the same.

As you could see, I tried really hard to avoid the re-configuration and re-compilation of the compiler but at the end it seems inevitable.
But it is enough for now, I feel really tired ;-)
We shall look at that in the next part.

Note: I have created a ticket on libtorrent Trac; it contains the diff with all the changes I have done.

WMU-6500FS - Deluge torrent (part I)

2008-07-24T14:06:00.027+02:00

Info sources: [Home page]

Overview

The deluge torrent client is first real X application (and the first application implemented in c++) I am trying to build on the WMU box. Thus it is by far the hardest puzzle I had to solve so far. I learned a lot along the way and so I would like to share it step by step with you.
Whole build process is so complicated for me, that I have not finished it yet (Update: it is finished now 8-) ) and so I am going to organize this post as series of three (hopefully there will be no need for more ;) parts. Also the deluge version was changing during my mission so the series will reflect these changes. It is not because I want to force readers (possibly trying to build the deluge as well) to go the exact same path, the point is to show all the problems (along with solutions or workarounds) I have experienced, since they can emerge in another situations as well.

This part contains the initial build process and deployment. Next part will deal with the local and remote debugging and (hopefully) the last one will describe the solution of the problems found during the debugging sessions. I am also going to prepare a post with build sequence of libraries the deluge directly or indirectly depends on.

Compilation:

I have started with the 0.5.9.1 version (the newest one at the time).

dev# wget http://download.deluge-torrent.org/source/0.5.9.1/deluge-0.5.9.1.tar.gz
dev# tar xzvf deluge-0.5.9.1.tar.gz
dev# export CFLAGS=-I/mnt/C/sys/include/boost-1_35
dev# python setup.py build
...
Error 1
libtorrent/src/session_impl.cpp:829:   instantiated from here
libtorrent/include/libtorrent/socket.hpp:181: error: `IPV6_V6ONLY' undeclared

It seems the uClibc (at least 0.9.27 version) lacks the IPV6_V6ONLY definition. See for example this message for more info about this (missing) define.
As a quick and dirty fix I just define the identifier locally:

dev# nano libtorrent/include/libtorrent/socket.hpp

... and add following (the actual value got from debian /usr/include/bits/in.h file) just after the include section:

#define IPV6_V6ONLY             26

Static linkage:

Now we can try the build again:

dev# python setup.py build
...
/usr/bin/ld: cannot find -lboost_filesystem-mt

Static linker is unable to find the boost_filesystem-mt library. At first we have to make sure that linker flags LDFLAGS are pointing to proper directory (sys/lib):

dev# echo $LDFLAGS

dev# export LDFLAGS=-L/mnt/C/sys/lib

... but the problem still persists. The problem is that the boost library names are more specific (contain boost version and compiler version). In README Additional notes is the following:

1) On some distributions, boost libraries are renamed to have "-mt" at the end (boost_thread_mt instead of boost_thread, for example), the "mt" indicating "multithreaded". In some cases it appears the distros lack symlinks to connect things. The solution is to either add symlinks from the short names to those with "-mt", or to alter setup.py to look for the "-mt" versions.

I do not know whether there should be libboost_*-mt.so symlinks by default, maybe I have not configured boost library properly, as a quick fix I decided to create the links manually:

dev# cd /mnt/C/sys/lib
dev# for i in `ls ./libboost_*-gcc33-mt-1_35.so.1.35.0`; do ln -s $i ${i/%-gcc33-mt-1_35.so.1.35.0/-mt.so}; done

Now we have another link error:

dev# python setup.py build
...
can't resolve symbol 'get_nprocs'

It seems that uClibc does not implement get_nprocs function. Following text from this forum describes the workaround:

I grep'ed the boost source tree for get_nprocs and found the only instance of it in thread.cpp. I found out that this function returns the number of processors and is really not needed in my case. So instead of having "return get_nprocs()", I changed it to "return 1". While I think this should not break anything, I thought I should still tell you.

So in file boost_1_35_0/libs/thread/src/pthread/thread.cpp I have replaced

    return get_nprocs();

with:

    return 1;

in short:

dev# cd /usr/local/src/boost_1_35_0
dev# sed -i 's/return get_nprocs();/return 1;/g' libs/thread/src/pthread/thread.cpp

... and rebuilt the boost library.

dev# make
...
...updating 3 targets...
...
...updated 3 targets...
dev# make install
...
...updating 6 targets...
common.copy /mnt/C/sys/lib/libboost_thread-gcc33-mt-1_35.so.1.35.0
ln-UNIX /mnt/C/sys/lib/libboost_thread-gcc33-mt-1_35.so
common.copy /mnt/C/sys/lib/libboost_wave-gcc33-mt-1_35.so.1.35.0
ln-UNIX /mnt/C/sys/lib/libboost_wave-gcc33-mt-1_35.so
common.hard-link /mnt/C/sys/lib/libboost_thread-gcc33-mt.so
common.hard-link /mnt/C/sys/lib/libboost_wave-gcc33-mt.so
...updated 6 targets...

... now the build finished successfully, we are ready to install:

dev# python setup.py install --prefix=/mnt/C/sys/X11

In order to correctly deploy on the box, one additional hack was needed (touch everything containing deluge in path so it is included in the filopack archive):

dev# find /mnt/C/sys -path "*deluge*" -type f -exec touch {} \;

We have the first step done. Do not know yet what is ahead of us ;-)

Dynamic linkage:

Now we can try to run the application:

dev# deluge
...
/usr/bin/python: can't resolve symbol '_ZN5boost6system19get_system_categoryEv'

It seems there is some symbol expected by deluge app but missing in the boost libraries.
With the nm command we find out whether the symbol is in any boost library:

dev# nm -A -D /mnt/C/sys/lib/libboost_* | grep "T _ZN5boost6system19get_system_categoryEv"
/mnt/C/sys/lib/libboost_system-gcc33-mt-1_35.so:00001d28 T _ZN5boost6system19get_system_categoryEv
/mnt/C/sys/lib/libboost_system-gcc33-mt-1_35.so.1.35.0:00001d28 T _ZN5boost6system19get_system_categoryEv
/mnt/C/sys/lib/libboost_system-gcc33-mt.so:00001d28 T _ZN5boost6system19get_system_categoryEv
/mnt/C/sys/lib/libboost_system-mt.so:00001d28 T _ZN5boost6system19get_system_categoryEv

Make sure that the symbol is needed from the deluge_core library:

dev# nm /mnt/C/sys/lib/python2.5/site-packages/deluge/deluge_core.so | grep _ZN5boost6system19get_system_categoryEv
         U _ZN5boost6system19get_system_categoryEv

We can test whether all the libraries the deluge_core depends on are properly found by the dynamic linker:

dev# ldd /mnt/C/sys/lib/python2.5/site-packages/deluge/deluge_core.so
        libboost_filesystem-gcc33-mt-1_35.so.1.35.0 => /usr/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_date_time-gcc33-mt-1_35.so.1.35.0 => /usr/lib/libboost_date_time-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        libboost_thread-gcc33-mt-1_35.so.1.35.0 => /usr/lib/libboost_thread-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        ...
        libboost_system-gcc33-mt-1_35.so.1.35.0 => /usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 (0x00000000)
        ...

I am not sure what exactly is going on here, I would be glad if anybody shed some light on it, as a workaround the LD_PRELOAD works for me:

dev# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 deluge
Traceback (most recent call last):
  File "/usr/bin/deluge", line 46, in 
    import deluge._dbus as dbus
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge/_dbus.py", line 32, in 
    from dbus import Interface, SessionBus, version
ImportError: No module named dbus

We have to install dbus before we proceed (see this post)...
Now we can try it again:

dev# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 deluge
process 16385: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open 

"/mnt/C/sys/X11//var/lib/dbus/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted

So far so good, following command seem to solve it:

dev# sys/X11/bin/dbus-uuidgen --ensure

... but then there is another problem:

Crashes:

#  LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 deluge
no existing Deluge session

(deluge:16391): GLib-GIO-CRITICAL **: g_unix_mount_is_system_internal: assertion `mount_entry != NULL' failed
Segmentation fault

The g_unix_mount_is_system_internal function (in glib-2.17.2/gio/gunixmounts.c file) asserted since the given mount_entry was NULL.

gboolean
g_unix_mount_is_system_internal (GUnixMountEntry *mount_entry)
{
  g_return_val_if_fail (mount_entry != NULL, FALSE);

  return mount_entry->is_system_internal;
}

Look at the places where the function is called. We find the g_unix_mount_guess_should_display function in the same file.

gboolean
g_unix_mount_guess_should_display (GUnixMountEntry *mount_entry)
{
  const char *mount_path;

  /* Never display internal mountpoints */
  if (g_unix_mount_is_system_internal (mount_entry))
    return FALSE;

  /* Only display things in /media (which are generally user mountable)
     and home dir (fuse stuff) */
  mount_path = mount_entry->mount_path;

It is apperent that this function calls the g_unix_mount_is_system_internal it asserts but returns FALSE and so the g_unix_mount_guess_should_display immediatelly crashes.
Now we can look at the caller's code, to the _g_unix_mount_new function in the glib-2.17.2/gio/gunixmount.c:

GUnixMount *
_g_unix_mount_new (GVolumeMonitor  *volume_monitor,
                   GUnixMountEntry *mount_entry,
                   GUnixVolume     *volume)
{
  GUnixMount *mount;

  /* No volume for mount: Ignore internal things */
  if (volume == NULL && !g_unix_mount_guess_should_display (mount_entry) )
    return NULL;
  ...

I do not know what are the exact contract of those functions, from the code it seems that all three functions share the precondition that the mount_entry cannot be NULL.
I decided not to go up on the call stack and look for the actual cause of the NULL mount_entry, it can very well be the fact that I am running on the chroot-ed environment. As a quick fix I modify this function as follows:

dev# nano /usr/local/src/glib-2.17.2/gio/gunixmount.c
  if (volume == NULL && ( !mount_entry || !g_unix_mount_guess_should_display (mount_entry) ) )
    return NULL;
dev# make 
dev# make install

Ok, let's try it again:
dev# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 /mnt/C/sys/X11/bin/deluge
no existing Deluge session
Traceback (most recent call last):
  File "/mnt/C/sys/X11/bin/deluge", line 130, in 
    deluge.wizard.WizardGTK()
  File "/mnt/C/sys/X11/lib/python2.5/site-packages/deluge/wizard.py", line 58, in __init__
    self.window.set_icon(deluge.common.get_logo(18))
  File "/mnt/C/sys/X11/lib/python2.5/site-packages/deluge/common.py", line 154, in get_logo
    size, size)
gobject.GError: Unrecognized image file format

When we look to the common.py we see there are two icon variants: svg and png. When we change .svg to .png everything works. You can open the file in a text editor:

dev# nano /mnt/C/sys/X11/lib/python2.5/site-packages/deluge/common.py
        return gtk.gdk.pixbuf_new_from_file_at_size(get_pixmap("deluge.png"), \
            size, size)

... or simply call the following command:

dev# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/X11/lib/python2.5/site-packages/deluge/common.py

Now we have made a progress, when we launch deluge the we have to setup the preferences.

But when we proceed, there is another error:

...
no existing Deluge session
Starting new Deluge session...
deluge_core; using libtorrent 0.13.0.0. Compiled with NDEBUG.
Applying preferences
Scanning plugin dir /mnt/C/sys/X11/share/deluge/plugins
Initialising plugin TorrentPeers
...
Initialising plugin SpeedLimiter
Applying preferences
Starting DHT...
Aborted

When we use strace tool to monitor system calls we get the following:

dev# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 strace deluge
...
close(11)                               = 0
write(1, "Applying preferences\n", 21Applying preferences
)  = 21
write(1, "Starting DHT...\n", 16Starting DHT...
)       = 16
open("/root/.config/deluge/dht.state", O_RDONLY) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(31503, SIGABRT)                    = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
Process 31503 detached

It seems the abort could have some relation with missing dht.state file. Let's try to debug it:

dev# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 gdb python
GNU gdb 6.3
...
(gdb) run /mnt/C/sys/X11/bin/deluge
Starting program: /mnt/C/sys/bin/python /mnt/C/sys/X11/bin/deluge
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 7763)]
Could not open /proc/7763/status

It seems it is not so easy to run gdb on chroot-ed system, I have tried mess up with manual /proc "dummy" file creation but had no success.
Another possibility is to debug directly on the box. Before that we have to upload it.

Deployment to the box:

After the upload routine some more problems emerged:

box# deluge
Traceback (most recent call last):
  File "/mnt/C/sys/X11/bin/deluge", line 43, in 
    import deluge
  File "/mnt/C/sys/X11/lib/python2.5/site-packages/deluge/__init__.py", line 34, in 
ImportError: No module named pygtk

Ok, I forgot to deploy pygtk. Done.

box# deluge
Traceback (most recent call last):
  File "/mnt/C/sys/X11/bin/deluge", line 45, in 
    import deluge.core
  File "/usr/lib/python2.5/site-packages/deluge/core.py", line 59, in 
    import deluge_core
ImportError: File not found

This one is more interesting, we have to find out what is going on:

box# strace python
...
import deluge.deluge_core
...
open("./libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/mnt/C/sys/lib//libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/mnt/C/sys/X11/lib//libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libboost_filesystem-gcc33-mt-1_35.so.1.35.0", O_RDONLY) = -1 ENOENT (No such file or directory)
close(3)                                = 0
write(2, "Traceback (most recent call last"..., 35Traceback (most recent call last):
) = 35
...

Ok, it seems we forgot to deploy the boost libraries. Done.

box# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 deluge
no existing Deluge session

(deluge:19324): libglade-WARNING **: could not find glade file '/usr/share/deluge/glade/wizard.glade'
Traceback (most recent call last):
  File "/mnt/C/sys/X11/bin/deluge", line 130, in 
    deluge.wizard.WizardGTK()
  File "/usr/lib/python2.5/site-packages/deluge/wizard.py", line 50, in __init__
    , domain='deluge')
RuntimeError: could not create GladeXML object

We have to create a symlink in /usr/share (since it is just memory filesystem, in order to make it permanent we have to make symlink anytime the box boots up).
For now just call following command, later on we can modify an config file (e.g. /mnt/C/sys/etc/rc-local).

box# ln -s /mnt/C/sys/share/deluge /usr/share/deluge

When we try to launch it again, we get known "Unrecognized image file format" message.

box# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 deluge
no existing Deluge session
Traceback (most recent call last):
  File "/mnt/C/sys/X11/bin/deluge", line 130, in 
    deluge.wizard.WizardGTK()
  File "/mnt/C/sys/X11/lib/python2.5/site-packages/deluge/wizard.py", line 58, in __init__
    self.window.set_icon(deluge.common.get_logo(18))
  File "/mnt/C/sys/X11/lib/python2.5/site-packages/deluge/common.py", line 154, in get_logo
    size, size)
gobject.GError: Unrecognized image file format

Stream editor helps us to fix it:

box# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/X11/lib/python2.5/site-packages/deluge/common.py

Now when run it under strace again, and it seems that we got on the box# system as far as we were on the dev# system:

box# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 strace deluge
...
close(11)                               = 0
write(1, "Applying preferences\n", 21Applying preferences
)  = 21
write(1, "Starting DHT...\n", 16Starting DHT...
)       = 16
open("/root/.config/deluge/dht.state", O_RDONLY) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(31503, SIGABRT)                    = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
Process 31503 detached

Local debugging:

Now we are ready to try the gdb debugger:

box# LD_PRELOAD=/usr/lib/libboost_system-gcc33-mt-1_35.so.1.35.0 gdb python
...
(gdb) run /mnt/C/sys/X11/bin/deluge
Starting program: /bin/python /mnt/C/sys/X11/bin/deluge
...
no existing Deluge session
Starting new Deluge session...
deluge_core; using libtorrent 0.13.0.0. Compiled with NDEBUG.

Program received signal SIG32, Real-time event 32.
0x4019cb64 in __rt_sigsuspend () from /lib/libc.so.0
(gdb) Quit
(gdb) where
#0  0x4019cb64 in __rt_sigsuspend () from /lib/libc.so.0
#1  0x4019cb9b in sigsuspend () from /lib/libc.so.0
#2  0x40139cf9 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#3  0x401396bd in pthread_create () from /lib/libpthread.so.0
#4  0x416c9f26 in boost::thread::start_thread () from /mnt/C/sys/lib//libboost_thread-gcc33-mt-1_35.so.1.35.0
#5  0x415d68c8 in disk_io_thread (this=0x821acc8, block_size=-4) at thread.hpp:151
...

Sig32 event is not really what we are looking for (some info about it can be seen in this discussion), we wait for the ABORT signal and so can continue:

(gdb) cont
Continuing.
Program received signal SIG32, Real-time event 32.
0x4019cb64 in __rt_sigsuspend () from /lib/libc.so.0
(gdb) cont
Continuing.
...
Applying preferences
Scanning plugin dir /usr/share/deluge/plugins
...
Starting DHT...

Program received signal SIGABRT, Aborted.
0x4019b1c4 in kill () from /lib/libc.so.0

So let's look where the problem is:

(gdb) where
#0  0x4019b1c4 in kill () from /lib/libc.so.0
#1  0x4013af69 in pthread_kill () from /lib/libpthread.so.0
#2  0x4013b37f in raise () from /lib/libpthread.so.0
#3  0x40194cc7 in abort () from /lib/libc.so.0
#4  0x4027140f in __cxa_call_unexpected () from /mnt/C/sys/lib//libstdc++.so.5
#5  0x40271439 in std::terminate () from /mnt/C/sys/lib//libstdc++.so.5
#6  0x40271560 in __cxa_throw () from /mnt/C/sys/lib//libstdc++.so.5
#7  0x41638218 in libtorrent::bdecode<std::istream_iterator<char, char, 
std::char_traits<char>, int> > (end= {<std::iterator<std::input_iterator_tag, char, int, char const*, char 
const&>> = {<No data fields>}, _M_stream = 0x8d188, _M_value = -124 
'\204', _M_ok = 88}) at bencode.hpp:332
#8  0x41632d47 in torrent_start_DHT (self=0x0, args=0x41a6d44c) at basic_ios.h:110
#9  0x4005d122 in PyCFunction_Call (func=0x412712ac, arg=0x41a6d44c, kw=0x6) at Objects/methodobject.c:108
#10 0x400a2661 in call_function (pp_stack=0xbfffec5c, oparg=0) at Python/ceval.c:3573
...

So we can see an exception thrown in libtorrent::bdecode which causes the immediate process termination. As far as I know it can be caused either by not-catching the exception or by a double throw. Here and here are examples when one experiences the same.

This is enough for today, we shall look at it in the next part. Since the local debugging is reaaaallyyyyy sloooow and several times I have even run out of swap space, in next part we also look at the remote debugging.

WMU-6500FS - Mesa 7.0.3

2008-07-09T21:32:00.002+02:00

Following image demonstrates the Mesa 3d application running on the box. As can be seen from FPS, there is no HW acceleration :-)

Build results (library): [binary] [files list]
Build results (demos): [binary] [files list]
Info sources: [Home page] [MesaLib dependencies]
Related info: [Xming notes] [Remote desktop for linux] [Compiling Mesa fbdev/DRI drivers without X installed]

For now we try to compile the stand-alone/Xlib mode (no Hardware acceleration necessary ;-)

Dependencies: [file 4.24] [Xorg libraries]

First we have to download and extract the libraries and related stuff:

dev# cd /usr/local/src
dev# wget "http://downloads.sourceforge.net/mesa3d/MesaLib-7.0.3.tar.bz2?modtime=1207336858&big_mirror=0"
dev# tar xjvf MesaLib-7.0.3.tar.bz2
dev# wget "http://downloads.sourceforge.net/mesa3d/MesaDemos-7.0.3.tar.bz2?modtime=1207336927&big_mirror=0"
dev# tar xjvf MesaDemos-7.0.3.tar.bz2
dev# wget "http://downloads.sourceforge.net/mesa3d/MesaGLUT-7.0.3.tar.bz2?modtime=1207336986&big_mirror=0"
dev# tar xjvf MesaGLUT-7.0.3.tar.bz2 
dev# cd Mesa-7.0.3

Now it is necessary to modify the configuration files, we have to replace the following two paths in the configs/linux:

dev# nano configs/linux

#X11_INCLUDES = -I/usr/X11R6/include
X11_INCLUDES = -I/mnt/C/sys/X11/include

#EXTRA_LIB_PATH = -L/usr/X11R6/lib
EXTRA_LIB_PATH = -L/mnt/C/sys/X11/lib

Also we have to alter the installation paths int the configs/default:

dev# nano configs/default

#INSTALL_DIR = /usr/local
INSTALL_DIR = /mnt/C/sys/X11

#DRI_DRIVER_INSTALL_DIR = /usr/X11R6/lib/modules/dri
DRI_DRIVER_INSTALL_DIR = /mnt/C/sys/X11/lib/modules/dri

No we are ready build:

dev# make linux-x86
...
../../lib/libGL.so: undefined reference to `posix_memalign'
collect2: ld returned 1 exit status

Regarding to this forum topic the posix_memalign is currently not implemented in uClibc so we have to disable it.
So let's back to the configuration file:

dev# nano configs/linux

DEFINES = -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE \
        -D_BSD_SOURCE -D_GNU_SOURCE \
        -DPTHREADS -DUSE_XSHM
# -DHAVE_POSIX_MEMALIGN

Now we try the build...

dev# make linux-x86

... and it completed successfully.

We are ready to start testing some demo apps, we try the notorious gears application:

#dev /mnt/C/sys/bin/mesa-demos/gears

If you get an error message similar to this:

Error: Can't open display:

... you probably did not configured the DISPLAY environment variable properly. For a hint how to do that see the X client/server configuration.

We have now the X client/server properly configured, gears test passed with no problems, we are ready to deploy on the box.
Curiously on the box we observe the following crash:

box# /mnt/C/sys/bin/mesa-demos/gears
Illegal instruction

To get to the heart of the matter we have to digg little deeper, however we need a tool for it. Let's try JoKeR's built version of gdb. For now we are going to debug directly at the box, later on we look at the remote debugging.

box# gdb /mnt/C/sys/bin/mesa-demos/gears
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux-uclibc"...Using host libthread_db library "/mnt/C/sys/lib/libthread_db.so.1".

(gdb) run
Starting program: /tmp/mnt/C/sys/bin/mesa-demos/gears
warning: Cannot initialize thread debugging library: generic error


Program received signal SIGILL, Illegal instruction.
_mesa_x86_cpuid () at x86/common_x86_asm.S:80
80      x86/common_x86_asm.S: No such file or directory.
        in x86/common_x86_asm.S
Current language:  auto; currently asm
(gdb) backtrace
#0  _mesa_x86_cpuid () at x86/common_x86_asm.S:80
#1  0x403053f0 in ?? () from /mnt/C/sys/lib/libGL.so.1
#2  0x4031f980 in quad_tab () from /mnt/C/sys/lib/libGL.so.1
#3  0x4021c24a in _mesa_init_all_x86_transform_asm () at x86/common_x86.c:180
#4  0x4016a17d in _math_init_transformation () at math/m_xform.c:214
#5  0x4016a19a in _math_init () at math/m_xform.c:227
#6  0x400e8674 in one_time_init (ctx=0x8056b38) at main/context.c:368
#7  0x400e75e1 in _mesa_initialize_context (ctx=0x8056b38, visual=0x8054688,
    share_list=0x0, driverFunctions=0xbffff6c0, driverContext=0x0) at main/context.c:1067
#8  0x4026f92b in XMesaCreateContext (v=0x8054688, share_list=0x0)
    at drivers/x11/xm_api.c:1504
#9  0x4026c234 in Fake_glXCreateContext (dpy=0x804cfa0, visinfo=0x8056900,
    share_list=0x0, direct=1) at drivers/x11/fakeglx.c:1401
#10 0x4026a46d in glXCreateContext (dpy=0x804cfa0, visinfo=0x8056900, shareList=0x0,
    direct=1) at drivers/x11/glxapi.c:188
#11 0x40020d22 in __glutCreateWindow (parent=0x0, x=0, y=0, width=300,
    height=1073998032, gameMode=0) at glut_win.c:609
#12 0x40020df3 in glutCreateWindow (title=0x804ae60 "Gears") at glut_win.c:731
#13 0x0804902e in main (argc=1, argv=0xbffffbc4) at gears.c:370
(gdb)

Ok, it seems promising, now we can look at the file in question:

dev# less /usr/local/src/Mesa-7.0.3/src/mesa/x86/common_x86_asm.S

... or we can look for example here on the web. At the line 80 we see the CPUID instruction:

...
76 :  MOV_L (REGOFF(4, ESP), EAX) /* cpuid op */
77 :  PUSH_L (EDI)
78 :  PUSH_L (EBX)
79 :  
80 :  CPUID
81 :  
82 :  MOV_L (REGOFF(16, ESP), EDI) /* *eax */
83 :  MOV_L (EAX, REGIND(EDI))
...

At the CPUID instruction description we can see what exactly the this instruction means and when it was introduced.
The following way we can find out the exact info about the CPU in the box:

box# cat /proc/cpuinfo
processor       : 0
vendor_id       : CyrixInstead
cpu family      : 4
model           : 1
model name      : Cx486SLC
stepping        : unknown
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : no
fpu_exception   : no
cpuid level     : -1
wp              : yes
flags           :
bogomips        : 44.33

In the document Application Note112 CyrixCPU Detection Guide I have found the following info:

The Cx486SLC, Cx486DLC, Cx486SRx2, Cx486DRx2, Cx486S, Cx486DX, Cx486DX2, and 5x86 processors do not recognize the CPUID instruction and must be identified using the DIR0 and DIR1 register.

So the cause of the problem is found. There is no support of certain instructions on the box and so we cannot be sure the code we built on the PC will run.
In the configuration file configs/linux-x86 we can see following ASM related switches:

ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM

In order not to use ASM implementations we can use linux configuration instead of linux-x86:

dev# make realclean
dev# make linux

Everything seem to be working now :-)

WMU-6500FS - GTK+ 2.10.14

2008-06-27T12:51:00.010+02:00

GTK+ 2.10.14

[Home page] [List of dependencies]

Build results: [binary] [list files]

Related stuff:
[XCB] [XCB util] [gperf] [cairo] [pango] [libtiff] [fontconfig]

Build sequence:

dev# cd /usr/local/src
dev# wget http://ftp.gnome.org/pub/gnome/sources/gtk+/2.10/gtk+-2.10.14.tar.bz2
dev# tar xjvf gtk+-2.10.14.tar.bz2
dev# ./configure --prefix=/mnt/C/sys
gdkdrawable-x11.c:32:24: cairo-xlib.h: No such file or directory

Not much of a progress. It seems we need to build the cairo library. Here are the details.

Now we can try to re-configure...

dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
configure: error:
*** Checks for TIFF loader failed. You can build without it by passing
*** --without-libtiff to configure but some programs using GTK+ may
*** not work properly

We can build it with the --without-libtiff option or we have to install the TIFF library.

Once it is done we can re-configure and make:

dev# export LDFLAGS=-L/mnt/C/sys/lib
dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
dev# make
...
 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\"Gdk\" -DGDK_COMPILATION 
-I../.. -I../../gdk -I../../gdk -DGDK_PIXBUF_DISABLE_DEPRECATED 
-DG_DISABLE_CAST_CHECKS -pthread -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo 
-I/mnt/C/sys/X11/include/ -g -O2 -Wall -MT gdkdrawable-x11.lo -MD -MP -MF 
.deps/gdkdrawable-x11.Tpo -c gdkdrawable-x11.c  -fPIC -DPIC -o 
libs/gdkdrawable-x11.o
gdkdrawable-x11.c:32:24: cairo-xlib.h: No such file or directory

It seems some modules try to directly include the cairo header files as they were placed at an include path, but that is not the case.

dev# export CXXFLAGS=-I/mnt/C/sys/X11/include/cairo
dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
dev# make
In file included from gdkdrawable-x11.c:32:
/mnt/C/sys/X11/include/cairo/cairo-xlib.h:97:3: #error Cairo was not compiled with support for the xlib backend

It seems we have to build the XCB library (Here is the build sequence) and then re-build the cairo library properly.

Now we are ready to proceed with GTK:

dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
...
configure:31390: gcc -o conftest -I/mnt/C/sys/X11/include/cairo -Wall -I/mnt/C/sys/X11/include
-L/mnt/C/sys/lib conftest.c -L/mnt/C/sys/X11/lib -lXext -lXrender -lX11  -lintl >&5
/mnt/C/sys/X11/lib/libxcb-xlib.so.0: undefined reference to `backtrace_symbols'
/mnt/C/sys/X11/lib/libxcb-xlib.so.0: undefined reference to `backtrace'

It seems that xcb is not properly configured, it needs a backtrace support (not provided by uClibc). So we have to rebuild libxcb with the HAVE_BACKTRACE configure hack.

Let's try it again, do not worry, we are almost there ;-)

dev# make clean
dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
dev# make
...
/bin/sh ../libtool --mode=link gcc  -I/mnt/C/sys/X11/include/cairo -Wall  
-L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -o gtk-query-immodules-2.0 queryimmodules.o 
libgtk-x11-2.0.la ../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-x11-2.0.la 
gcc -I/mnt/C/sys/X11/include/cairo -Wall -o .libs/gtk-query-immodules-2.0 
queryimmodules.o  -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib  ./.libs/libgtk-x11-2.0.so 
/usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so -L/mnt/C/sys/X11/lib 
/usr/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so 
../gdk/.libs/libgdk-x11-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libcairo.so 
/usr/lib/libpixman-1.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so 
...
/usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_create_for_bitmap'
/usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_create'
/usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so: undefined reference to `cairo_xlib_surface_set_size'
collect2: ld returned 1 exit status

It seems that the static linker did not find some cairo symbols.
Let's look to gdk to be sure what cairo symbols are referenced:

dev# nm /usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so | grep cairo_xlib_surface_create
         U cairo_xlib_surface_create
         U cairo_xlib_surface_create_for_bitmap

Let's look at the cairo library why they are missing...

dev# nm /mnt/C/sys/X11/lib/libcairo.so | grep cairo_xlib_surface_create
...
0005b7d3 T cairo_xlib_surface_create
0005b834 T cairo_xlib_surface_create_for_bitmap
...

It seems the symbols are there. If they was not there it would be due to incorrect cairo configuration, namely missing --with-x configure script option (see this mail). However I think that in this regard we have the cairo configured properly.

Not sure what is actually going on here, maybe it is the order of libraries passed to static linker (the fact that the libcairo.so goes after the libgdk-x11-2.0.so):

gcc -I/mnt/C/sys/X11/include/cairo -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o
-L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib ./.libs/libgtk-x11-2.0.so 
/usr/local/src/gtk+-2.10.14/gdk/.libs/libgdk-x11-2.0.so -L/mnt/C/sys/X11/lib 
/usr/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so 
../gdk/.libs/libgdk-x11-2.0.so /usr/lib/libpangocairo-1.0.so /usr/lib/libcairo.so 
/usr/lib/libpixman-1.so /usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so 
/usr/lib/libpng12.so /mnt/C/sys/X11/lib/libxcb-render-util.so /mnt/C/sys/X11/lib/libxcb-render.so 
/mnt/C/sys/X11/lib/libpixman-1.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so 
-lz /usr/lib/libexpat.so /mnt/C/sys/X11/lib/libXinerama.so 
/mnt/C/sys/X11/lib/libXrandr.so /mnt/C/sys/X11/lib/libXext.so 
...

In any case the following hack "fixed" the problem:

dev# make clean
dev# export LDFLAGS="-L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib /mnt/C/sys/X11/lib/libcairo.so"
dev# ./configure --prefix=/mnt/C/sys/X11/ --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
dev# make

Test installation:

Now we are ready to test the installation:

dev# /mnt/C/sys/X11/bin/gtk-demo
...
(gtk-demo:25684): Pango-CRITICAL **: No fonts found:
This probably means that the fontconfig
library is not correctly configured. You may need to
edit the fonts.conf configuration file. More information
about fontconfig can be found in the fontconfig(3) manual
page and on http://fontconfig.org
...

The application seems as follows:

The fonts are compiled and deployed but not installed correctly, when we build the fontconfig then we can perform the following test:

dev# fc-list
dev#

We have to create a link to /usr/share/ directory to make fonts visible:

dev# ln -s /mnt/C/sys/X11/lib/X11/fonts/ /usr/share/fonts
dev# fc-cache
dev# fc-list
Luxi Serif:style=Regular
LucidaBright:style=Italic
Utopia:style=Bold Italic
Serto Malankara:style=Regular
...

The startup time of the gtk-demo application (as well as for example simple xclock) increased significantly. It seems that number of fonts greatly influences the x-apps' startup times. When we (according to this source) limit the number of linked fonts (e.g. only OTF and TTF) (see alsho this tip), the situation is slightly better:

box# rm /usr/share/fonts
box# mkdir /usr/share/fonts
box# ln -sn $XORG_PREFIX/lib/X11/fonts/OTF /usr/share/fonts/X11-OTF &&
box# ln -sn $XORG_PREFIX/lib/X11/fonts/TTF /usr/share/fonts/X11-TTF

Still the x-client applications are relatively slow, turning the ssh compression helped a bit, but more evaluation and benchmarking is needed...

libxcb-1.1

[XCB dependencies]

Build results: [binary] [list files]

Build sequence: We can download XCB via the git_xorg.sh script (for details see XOrg related post) or we can do it by hand. As it is described here. First we have to download and build the protocol headers and pthread stubs (on linux it should be just stubs and nothing more).

dev# cd /usr/local/src
dev# wget http://xcb.freedesktop.org/dist/xcb-proto-1.1.tar.gz
dev# tar xzvf xcb-proto-1.1.tar.gz
dev# ./configure --prefix=/mnt/C/sys/X11
dev# make
dev# cp xcb-proto.pc /mnt/C/sys/X11/lib/pkgconfig/
dev# cd ..
dev# wget http://xcb.freedesktop.org/dist/libpthread-stubs-0.1.tar.bz2
dev# tar xjzf libpthread-stubs-0.1.tar.bz2
dev# cd libpthread-stubs-0.1
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

Now we can proceed to build the XCB itself:

dev# cd /usr/local/src
dev# wget http://xcb.freedesktop.org/dist/libxcb-1.1.tar.bz2
dev# tar xjvf libxcb-1.1.tar.bz2
dev# cd libxcb-1.1

In order to configure the it was necessary to set the PKG_CONFIG_PATH properly. Maybe it is a good idea to have it set on every boot...
For now we just set it one-shot:

dev# export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/mnt/C/sys/lib/pkgconfig/:/mnt/C/sys/X11/lib/pkgconfig/

Another problem was with backtrace symbols. During the static linking everything seem ok, but the runtime linker (when an application is launched) complains about missing symbols:

/mnt/C/sys/X11/lib/libxcb-xlib.so.0: undefined reference to `backtrace_symbols'
/mnt/C/sys/X11/lib/libxcb-xlib.so.0: undefined reference to `backtrace'

It seems that backtrace support is not implemented in uClibc 0.9.27. Regarding this ticket it should be present since version 0.9.28.
For now I decided to re-configure the library not to use the backtrace support at all. It is relatively simple - we just backup and alter the configure.ac file as follows:

dev# cat configure.ac | grep backtrace
AC_CHECK_HEADER([execinfo.h], [AC_DEFINE(HAVE_BACKTRACE,1,[Has backtrace*() needed for retrieving stack traces])])
dev# cp configure.ac{,.backup}   
dev# sed -i 's/AC_CHECK_HEADER(\[execinfo.h\],\[AC_DEFINE(HAVE_BACKTRACE/#AC_CHECK_HEADER(\[execinfo.h\],\[AC_DEFINE(HAVE_BACKTRACE/g' configure.ac
dev# cat configure.ac | grep backtrace
#AC_CHECK_HEADER([execinfo.h], [AC_DEFINE(HAVE_BACKTRACE,1,[Has backtrace*() needed for retrieving stack traces])])

One more time we re-configure and rebuild the library:

dev# make clean
dev# ./configure --prefix=/mnt/C/sys/X11
dev# make
dev# make install

Note: Regarding to the missing backtrace support we can also consider deleting the /usr/include/execinfo.h file instead of altering the configuration files.

dev# mv /usr/include/execinfo.h{,.deleted}

I do not know if it is correct solution but it seems logically the file contains just declarations of those backtrace related functions and the fact that is it not present fixes the behavior of configure scripts.
For more info see Problems compiling pdns using uClibc.

gperf-3.0.3

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://ftp.gnu.org/gnu/gperf/gperf-3.0.3.tar.gz
dev# tar xzvf gperf-3.0.3.tar.gz
dev# cd gperf-3.0.3
dev# ./configure --prefix=/mnt/C/sys/
dev# make
dev# make install

xcb-util-0.2

Dependencies: [gperf] [xcb]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://xcb.freedesktop.org/dist/xcb-util-0.2.tar.bz2
dev# tar xjvf xcb-util-0.2.tar.bz2
dev# ./configure --prefix=/mnt/C/sys/X11
dev# make
dev# make install

cairo-1.6.4

[Home page]

Dependencies: [xcb]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://cairographics.org/releases/cairo-1.6.4.tar.gz
dev# tar xzvf cairo-1.6.4.tar.gz
dev# cd cairo-1.6.4

Simply calling ./configure --prefix=/mnt/C/sys/X11 does not work with the GTK library, we have to configure the cairo with the Xlib support.

dev# ./configure --prefix=/mnt/C/sys/X11 --with-x -x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/ --enable-xlib=yes --enable-xlib-xrender=yes --enable-xcb=yes
cairo (version 1.6.4) will be compiled with the following surface backends:
  image:         yes (always builtin)
  Xlib:          yes
  Xlib Xrender:  yes
  Quartz:        no (CoreGraphics framework not found)
  Quartz-image:  no (disabled, use --enable-quartz-image to enable)
  XCB:           yes
  Win32:         no (requires a Win32 platform)
  OS2:           no (disabled, use --enable-os2 to enable)
  PostScript:    yes
  PDF:           yes
  SVG:           yes
  glitz:         no (disabled, use --enable-glitz to enable)
  BeOS:          no (disabled, use --enable-beos to enable)
  DirectFB:      no (disabled, use --enable-directfb to enable)

the following font backends:
  FreeType:      yes
  Win32:         no (requires a Win32 platform)
  Quartz:        no (CoreGraphics framework not found)

the following features:
  PNG functions: yes

and the following debug options:
  gcov support:  no
  test surfaces: no
  ps testing:    no (requires ghostscript)
  pdf testing:   no (requires poppler-glib >= 0.8.0)
  svg testing:   no (requires librsvg-2.0 >= 2.15.0)

using CFLAGS:
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/mnt/C/sys/X11/include -I/mnt/C/sys/XOrg/include -I/mnt/C/sys/XOrg/include -I/mnt/C/sys/XOrg/include/pixman-1 -Wall -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute 
-Wno-unused-parameter -Wno-long-long -Winline -fno-strict-aliasing

*** The XCB backend is still under active development and
*** is included in this release only as a preview. It does not
*** fully work yet and incompatible changes may yet be made
*** to XCB-backend specific API.

dev# make
dev# make install

libtiff 3.8.2

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget ftp://ftp.remotesensing.org/pub/libtiff/tiff-3.8.2.tar.gz
dev# tar xzvf tiff-3.8.2.tar.gz
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

pango-1.21.3

[Home page]

Dependencies: [cairo]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://ftp.gnome.org/pub/GNOME/sources/pango/1.21/pango-1.21.3.tar.bz2
dev# tar xjvf pango-1.21.3.tar.bz2
dev# cd pango-1.21.3
dev# ./configure --prefix=/mnt/C/sys/X11 --with-x --x-includes=/mnt/C/sys/X11/include/ 
--x-libraries=/mnt/C/sys/X11/lib/
dev# make
dev# make install

fontconfig-2.6.0

[Home page]

Build results: [binary] [list files]

Build sequence: We have to configure it to look at the /mnt/C/sys/X11/etc/fonts/ directory (instead of default /etc/fonts/) since the /etc directory is read-only (we are not even able to create a symlink).

dev# cd /usr/local/src
dev# wget http://fontconfig.org/release/fontconfig-2.6.0.tar.gz
dev# tar xzvf fontconfig-2.6.0.tar.gz
dev# cd fontconfig-2.6.0
dev# ./configure --prefix=/mnt/C/sys/X11 --with-confdir=/mnt/C/sys/X11/etc/fonts/
dev# make 
dev# make install

A curious AIX crash

2008-06-26T17:20:00.015+02:00

Few days ago we had to solve an odd crash on AIX platform (powerpc chip). The company I am working in as a developer uses mainly MS Windows as a development platform but supports Linux as well as Unix platforms (namely AIX, HP-UX and Solaris).
The crash was only on AIX and we was not able to replicate it on any other platform. Our Unix experience is not such as it should be so it is always painful process to solve it when such a platform specific bug appears.

What I am going to describe here is too technical and boring for a majority of people, and on the other side maybe too trivial for those UNIX developers more experienced than me, but I hope there could be some (evenly non-practiced) developers out there who could find this information helpful or at least interesting.

The crash we experienced was easily replicable and was always at the same place - there was a totally innocent looking member function, its code is something like the following:

virtual T const& get( unsigned int id ) const
{    <---------------------------- The crash was right here before anything happen
 if ( id < static_cast( m_values.size() ) )
  return get_internal( id );
 throw ExceptionNotFound( LOCARG, id, count() );
 UNREACHABLE_RETURN( T() );
}

The object instance was ok, the id parameter was in range <0, m_values.size() ), there was no apparent reason why it should crash. So it was necessary to sink at the assembly level. The code for this function started as follows (PowerPC Stack Attacks helped us to interpret the code):

0x39927250 (get(unsigned int) const)      7c0802a6       mflr   r0              Function call prologue routine
0x39927254 (get(unsigned int) const+0x4)  93e1fffc        stw   r31,-4(r1)      (seems like the registers are 
0x39927258 (get(unsigned int) const+0x8)  93c1fff8        stw   r30,-8(r1)       associated with individual local
0x3992725c (get(unsigned int) const+0xc)  93a1fff4        stw   r29,-12(r1)      variables)
0x39927260 (get(unsigned int) const+0x10) 9381fff0        stw   r28,-16(r1)
0x39927264 (get(unsigned int) const+0x14) 9361ffec        stw   r27,-20(r1)
0x39927268 (get(unsigned int) const+0x18) 9341ffe8        stw   r26,-24(r1)
0x3992726c (get(unsigned int) const+0x1c) 90010008        stw   r0,0x8(r1)
0x39927270 (get(unsigned int) const+0x20) 9421ed30       stwu   r1,-4816(r1)  -> Here was the place of the segfault
0x39927274 (get(unsigned int) const+0x24) 83e2017c        lwz   r31,0x17c(r2)    
0x39927278 (get(unsigned int) const+0x28) 83c20180        lwz   r30,0x180(r2)    What the coed does is that a new stack frame 
...                                                                              is "allocated" and the stack pointer register 
                                                                                 (r1) is updated

                                                                                 "stwu" instruction stores the current content of 
                                                                                 the r1 register at address computed as (r1-offset) 
                                                                                 and decrements the r1 by offset at the same time
                                                                                 (offset is 4816 bytes in this case)

Initially we thought that due to the stack corruption the the stack pointer (r1) contain incorrect address (pointing to a read-only memory page) and so the write operation to that address failed.
Here is the stack pointer register value:

(dbx) registers
  $r0:0x3d1dd854  $stkp:0x400f5cb0   $toc:0x3a7071dc    $r3:0x40146fb0
  ...

When we looked to the address 0x400f5cb0 we could see an address of the previous frame, at that address was the previous one and over and over. This way was possible to traverse down to the stack and everything seemed consistent. The stack did not seem to be corrupted at all.

(dbx) 0x400f5cb0/4X
0x400f5cb0:  400f5d00 00000000 3d2b2854 00000000      (   80 bytes)
(dbx) 0x400f5d00/4X
0x400f5d00:  400f7010 00000000 3d2b228c 00000000      ( 4880 bytes)
(dbx) 0x400f7010/4X
0x400f7010:  400f70e0 00000000 3d2b410c 00000000      (  208 bytes)
(dbx) 0x400f70e0/4X
0x400f70e0:  400fd560 00000000 3d287294 00000000      (25728 bytes)
(dbx) 0x400fd560/4X
0x400fd560:  401026e0 00000000 3d289bd0 00000000      (20864 bytes)
(dbx) 0x401026e0/4X
0x401026e0:  40102750 00000000 3d28a0cc 00000000      (  112 bytes)

The interesting part was the stack frame size (4816 bytes) - the fact that the memory at the current stkp address seemed to contain a consistent data while the attempt to write to an address computed as 0x400f5cb0-4816 == 0x400f49e0 results in the segmentation violation brought us to an idea that it could be the stack overflow.

The documentation at the IBM Systems Information Center describes the following structure of call stack and related data structures (for whole documentation see this page):

     *      +-----------------------+
     *      | page alignment 2      |
     *      | [8K-4K+PTH_FIXED-a1]  |
     *      +-----------------------+
     *      | pthread ctx [368]     |
     *      +-----------------------+<--- pthread->pt_attr
     *      | pthread attr [112]    |
     *      +-----------------------+ <--- pthread->pt_attr
     *      | pthread struct [960]  |
     *      +-----------------------+ <--- pthread
     *      | pthread stack         |         pthread->pt_stk.st_limit
     *      |   |[96K+4K-PTH_FIXED] |
     *      |   V                   |
     *      +-----------------------+ <--- pthread->pt_stk.st_base
     *      | RED ZONE [4K]         |
     *      +-----------------------+ <--- pthread->pt_guardaddr
     *      | pthread key data [4K] |
     *      +-----------------------+ <--- pthread->pt_data
     *      | page alignment 1 (a1) |
     *      | [<4K]                 |
     *      +-----------------------+
     
     The RED ZONE on this illustration is called the Guardpage.

The decimal number of guard pages to add to the end of the pthread stack is n, which overrides the attribute values 
that are specified at pthread creation time. If the application specifies its own stack, no guard pages are created. 
The default is 0 and n must be a positive value.
The guardpage size in bytes is determined by multiplying n by the PAGESIZE. Pagesize is a system-determined size.

The relatively small default call stack size (96K) supported our hypothesis. We needed just to find a proof that the address being written to is actually the RED ZONE.

Here is the memory dump retrieved from the dbx along with my comments (please note that the address orientation is reversed relatively to previous schema):

(dbx) 0x400f3fe8/2048X
0x400f3fe8:  00000000 00000000 00000000 00000000  ------> Bottom of another thread's call stack
0x400f3ff8:  00000001 40135cac 40135cac 40135cac  ----> 
0x400f4008:  f0286708 f0286708 f0286708 f0286708  ----> Guard page (aka "Red zone")
0x400f4018:  f0286708 f0286708 f0286708 f0286708        Read/write protected memory region
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   (4096 bytes)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x400f49c8:  f0286708 f0286708 f0286708 f0286708
0x400f49d8:  f0286708 f0286708 f0286708 f0286708  <---.  BOOM (Segmentation fault)
0x400f49e8:  f0286708 f0286708 f0286708 f0286708      |  Attempt to write to the 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |  "red zone" (guard page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |   
0x400f4fe8:  f0286708 f0286708 f0286708 f0286708      |
0x400f4ff8:  f0286708 f0286708 00000000 00000000   ---+-> Top of the current thread's call stack
0x400f5008:  00000000 00000000 00000000 00000000      |   
0x400f5018:  00000000 00000000 00000000 00000000      |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  |
0x400f5988:  00000000 00000000 00000000 00000000      | 
0x400f5c78:  00000000 00000000 400f5cd0 00000000      | 4816 bytes
0x400f5c88:  00000000 00000000 00000000 00000000      |
0x400f5c98:  400fd5b8 401ad028 4019fa58 40165f90    --'
0x400f5ca8:  3d4263e8 3d9981e8 400f5d00 00000000  <---.
0x400f5cb8:  3d2b2854 00000000 401ad028 3d9bd578      |
0x400f5cc8:  00000000 00000000 400f5d20 00000000      |
0x400f5cd8:  39a87794 00000000 00000000 00000000      |
0x400f5ce8:  40165cc4 00000000 00000000 00000000    --'   80 bytes 
0x400f5cf8:  00000000 00000000 400f7010 00000000  <---.
0x400f5d08:  3d2b228c 00000000 401ad028 00000000      |
0x400f5d18:  40165f90 00000000 400f6ff0 00000000      |
0x400f5d28:  39a74c24 00000000 00000000 00000000      |
0x400f5d38:  40165cc0 00000000 00000000 00000000      |  4880 bytes
0x400f5d48:  00000000 00000000 00000000 00000000      |
0x400f5d58:  00000000 00000000 00000000 00000000      | 
0x400f5d68:  00000000 00000000 00000000 00000000      . Linked list of current thread's stack frames
0x400f5d78:  00000000 00000000 00000000 00000000      . 
(dbx)

Those almost 5 kilobytes stack frames were caused by Exception objects residing on stack. Our exception implementation holds relatively big array of wide characters (to avoid heap allocations in case of a failure) and so in some cases the exceptions (though not thrown, just prepared on stack to be thrown in case something fails) consume substantial portion of stack memory and finally cause the stack overflow error.

Just now I am quite happy that we have found and solved this problem and at the same time have learned something new.

It is necessary to a priori know the maximum call stack size and the default values for AIX system are relatively low. Since the architecture has no special support for the call stack, the only available diagnostics is a Guard page (aka Red zone). It is implemented as N read/write protected memory pages mapped above the call stack limit (please, node that regarding the documentation this functionality is disabled by default). A Stack overflow event then (if you are lucky) causes the "normal" segmentation violation - the same as as any other invalid access to a protected memory region and so it is relatively difficult to diagnose for a developers with not much platform-specific experience.

Post note: There is an interesting document about method called "Automatically Extensible Discontinuous Stacks" - a method eliminating the need of the stack size pre-knowledge.

WMU-6500FS - X.Org 7.1 (updated)

2008-06-25T23:35:00.007+02:00

Just for fun I am trying to build X.Org and it seems it won't be such a problem to finish it. There are many issues remaining to be solved but at least for now I am able to run couple of simple X-applications.
Update: I have not finished the X server yet, but have built X.Org libraries, so now it is possible to build X client applications.
Build results: [binary (82MB)] [list files]

Following image demonstrates the xcalc application running on the box acting as X-client of the XMing server running on my PC :-)

Dependencies: [m4-1.4.11] [libxslt-1.1.22] [xmlto 0.0.20] [Mesa 7.0.3] [rsh (fake with ssh alias)]
Info sources:
[X Window System Environment]
[Modular Developer's Guide]
[Modular X development using the git trees]
[Embedded Linux Graphics Quick Reference Guide]

Build sequence:
Create source directory and download git_xorg script (will be used to get all xorg modular components from git repository)

dev# cd /usr/local/src
dev# mkdir Xorg
dev# cd Xorg
dev# wget "http://www.x.org/wiki/ModularDevelopersGuide?action=AttachFile&do=get&target=git_xorg.sh" -O git_xorg.sh
dev# chmod a+x git_xorg.sh
dev# echo "do_dir xorg font \"\${font}\"        # this line added to get fonts" >> git_xorg.sh

Customize git_xorg script

dev# nano git_xorg.sh

... you can for example remove all xf86-video-* drivers and related stuff, remove do_dir . xcb "${xcb}", add do_dir xorg font "${font}" in order to download fonts, etc.

dev # diff git_xorg.sh git_xorg.sh.orig
50c50,65
<       xf86-input-vmmouse xf86-input-void"
---
>       xf86-input-vmmouse xf86-input-void xf86-video-apm\
>       xf86-video-ark xf86-video-ast xf86-video-ati\
>       xf86-video-chips xf86-video-cirrus xf86-video-cyrix\
>       xf86-video-dummy xf86-video-fbdev xf86-video-glide\
>       xf86-video-glint xf86-video-i128 xf86-video-i740\
>       xf86-video-impact xf86-video-imstt xf86-video-intel\
>       xf86-video-mga xf86-video-neomagic xf86-video-newport\
>       xf86-video-nsc xf86-video-nv xf86-video-rendition\
>       xf86-video-s3 xf86-video-s3virge xf86-video-savage\
>       xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb\
>       xf86-video-sunbw2 xf86-video-suncg14 xf86-video-suncg3\
>       xf86-video-suncg6 xf86-video-sunffb xf86-video-sunleo\
>       xf86-video-suntcx xf86-video-tdfx xf86-video-tga\
>       xf86-video-trident xf86-video-tseng xf86-video-v4l\
>       xf86-video-vesa xf86-video-vga xf86-video-via\
>       xf86-video-vmware xf86-video-voodoo xf86-video-wsfb"
129c144
< do_dir xorg font "${font}"        # this line added to get fonts
---
> do_dir . xcb "${xcb}"

Now we can start downloading the source:

dev# ./git_xorg.sh

And now we can try to run the build (we have not solved any dependencies yet, I decided to solve it along the way).
The first one is the m4 preprocessor:

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh /mnt/C/sys/X11
    ...
    autom4te: need GNU m4 1.4 or later: /usr/bin/m4

For info how to get and build the m4 preprocessor see this post.
Then there is xcb build error (in case one have not removed it from the git_xorg.sh):

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh /mnt/C/sys/X11
    ...
     configure: error: XCB requires xsltproc.
    /mnt/C/sys/X11/lib/libxcb-xlib.so: undefined reference to `backtrace_symbols'
    /mnt/C/sys/X11/lib/libxcb-xlib.so: undefined reference to `backtrace'

It seems that uClibc does not implement the backtrace related stuff. As a solution we can re-configure the xcb:

dev# cp xcb/libxcb/configure.ac{,.backup}
dev# nano xcb/libxcb/configure.ac

From the configure.ac comment out the following line:

    AC_CHECK_HEADER([execinfo.h], [AC_DEFINE(HAVE_BACKTRACE,1,[Has backtrace*() ...

And then we can continue the build process, the next error is in the libXcomposite:

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r xcb/libxcb /mnt/C/sys/X11
    ...
    make[3]: Entering directory `/usr/local/src/Xorg/lib/libXcomposite/man'
    WARNING: configure did not find xmlto, cannot create Xcomposite.man without it

For info how to get and build the xmlto see this post.
The next problem was in xconsole application:

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r lib/libXcomposite /mnt/C/sys/X11
...
make[1]: Entering directory `/usr/local/src/Xorg/app/xconsole'
...
In file included from xconsole.c:185:
/usr/include/sys/stropts.h:1:21: stropts.h: No such file or directory

uClibc does not implement streams and so the fact that the stropts.h header file is missing is understandable.
Commenting out the include in xconsole.c file semms to work. For more info about this issue see this source.
After the xconsole.c modification we can try to continue the build process:

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r app/xconsole /mnt/C/sys/X11
...
Building app module component xdriinfo...
...
configure: error: cannot find GL library - make sure Mesa or other OpenGL package is installed

For info how to get and build Mesa library see this post.
After that we have to add the new include and library dirs to the environment:

dev# export LDFLAGS="-lGL -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -lX11"
dev# export CFLAGS=-I/mnt/C/sys/include

And then we can continue.

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r app/xdriinfo -m /usr/local/src/Mesa-7.0.3 /mnt/C/sys/X11
...
Building app module component xsm...
...
configure: error: No rsh like program found

For more details about this issue see this message.

At the time I had not even the dropbear/ssh installed I decided to install it and solve the lack of rsh binary with the following fake:

dev# cd /mnt/C
dev# wget http://mgb111.pradnik.net/addons/servers-ssh/dropbear-ssh-sshd-050.3.tgz
dev# tar xzvf dropbear-ssh-sshd-050.3.tgz
dev# which ssh
/mnt/C/sys/bin/ssh

Now we can create rsh names alias for the ssh binary.

dev# ln -s /mnt/C/sys/bin/{s,r}sh
dev# rsh
Dropbear multi-purpose version 0.50
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'dropbearconvert' - the key converter
'scp' - secure copy
dev# ls -l /mnt/C/sys/bin/rsh
lrwxrwxrwx  2 root root 18 Jun 25 14:42 /mnt/C/sys/bin/rsh -> /mnt/C/sys/bin/ssh*
dev# ls -l /mnt/C/sys/bin/ssh
lrwxrwxrwx  1 root root 13 Jun 17 14:34 /mnt/C/sys/bin/ssh -> dropbearmulti*

The symlink method does not work. It is because of the fact that dropbear is the multiapplication and so the ssh binary is actually a symlink pointing to the binary called dropbearmulti binary. For such case the szmlink name matters, it can be one of the names listed above.
We have another possibility, we can create a shell script calling ssh along with all its command line arguments:

dev# echo "\
> #!/bin/bash
> ssh \$1 \$2 \$3 \$4 \$5 \$6 \$7 \$8 \$9" > /mnt/C/sys/bin/rsh
dev# cat /mnt/C/sys/bin/rsh
#!/bin/bash
ssh $1 $2 $3 $4 $5 $6 $7 $8 $9
dev# chmod a+x /mnt/C/sys/bin/rsh
dev# rsh
Dropbear client v0.50
Usage: ssh [options] [user@]host [command]
Options are:
...

Now back to the Xorg source directory and continue the building process:

dev# cd /usr/local/src/Xorg
dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r app/xsm -m /usr/local/src/Mesa-7.0.3 /mnt/C/sys/X11
Building xserver module ...
...
checking for GL... configure: error: Package requirements (glproto >= 1.4.9 gl >= 7.1.0) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively you may set the GL_CFLAGS and GL_LIBS environment variables
to avoid the need to call pkg-config.  See the pkg-config man page for
more details.

For now we can skip the xserver as well as the driver (we are interested in xclients mainly) modules:

dev# PATH=/mnt/C/sys/X11/bin:$PATH ./util/modular/build.sh -r font/util -m /usr/local/src/Mesa-7.0.3 /mnt/C/sys/X11
...
xcb module component util does not exist, skipping.
Wed Jun 25 13:21:59 MDT 2008

***** Skipped components (not available) *****
 xcb/util

For now we are done with X.Org libraries, except the xserver, drivers and xcb. Maybe we come back to that later...

WMU-6500FS - mpd-0.13.2

2008-06-20T17:49:00.007+02:00

mpd-0.13.2

[Home page]

Build results: [binary] [list files]

Dependencies: [libao] [libid3tag] [flac] [libmad] [audiofile] [faad2] [libmikmod] [libogg-1.1.3] [libvorbis-1.2.0]

Build sequence:

dev# cd /usr/local/src
dev# wget http://www.musicpd.org/uploads/files/mpd-0.13.2.tar.bz2
dev# tar xjvf mpd-0.13.2.tar.bz2
dev# cd cd mpd-0.13.2
dev# export PKG_CONFIG_PATH=/mnt/C/sys/lib/pkgconfig:$PKG_CONFIG_PATH
dev# ./configure --prefix=/mnt/C/sys --enable-ao --enable-mvp --with-libFLAC=/mnt/C/sys
...
########### MPD CONFIGURATION ############

 Playback Support:
 libao support .................enabled
 OSS support ...................enabled
 ALSA support ..................disabled
 JACK support ..................disabled
 OS X support ..................disabled
 PulseAudio support ............disabled
 Media MVP support .............enabled
 Shout streaming support .......disabled

 File Format Support:
 ID3 tag support ...............enabled
 mp3 support ...................enabled
 Ogg Vorbis support ............enabled
   using tremor.................no
 FLAC support ..................enabled
 OggFLAC support ...............enabled(FLAC 1.1.3)
 Wave file support .............enabled
 MP4/AAC support ...............enabled
 Musepack (MPC) support ........disabled
 MOD support ...................disabled

 Other features:
 libsamplerate support .........disabled
 Zeroconf support ..............disabled

##########################################

Some dependency libraries are still not found succesfully, hopefully I will solve it later...

dev# make
dev# make install

libao-0.8.8

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://downloads.xiph.org/releases/ao/libao-0.8.8.tar.gz
dev# tar xzvf libao-0.8.8.tar.gz
dev# cd libao-0.8.8
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

libid3tag-0.15.1b

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget ftp://ftp.mars.org/pub/mpeg/libid3tag-0.15.1b.tar.gz
dev# tar xzvf libid3tag-0.15.1b.tar.gz
dev# cd libid3tag-0.15.1b
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

libmad-0.15.1b

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget ftp://ftp.mars.org/pub/mpeg/libmad-0.15.1b.tar.gz
dev# tar xzvf libmad-0.15.1b.tar.gz
dev# cd libmad-0.15.1b
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

flac-1.2.1

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget "http://downloads.sourceforge.net/flac/flac-1.2.1.tar.gz?modtime=1189961849&big_mirror=0"
dev# tar xzvf flac-1.2.1.tar.gz
dev# cd flac-1.2.1
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

audiofile-0.2.6

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://www.68k.org/~michael/audiofile/audiofile-0.2.6.tar.gz
dev# tar xzvf audiofile-0.2.6.tar.gz
dev# cd audiofile-0.2.6
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

faad2-2.6.1

[Home page]

Build results: [binary] [list files]

Dependencies: [Perl >= 5.005] [GNU m4 >= 1.4]

Build sequence:

dev# cd /usr/local/src
dev# wget http://downloads.sourceforge.net/faac/faad2-2.6.1.tar.gz
dev# tar xzvf faad2-2.6.1.tar.gz
dev# cd faad2
dev# autoreconf -vif
Perl 5.005 required--this is only version 5.00405, stopped at /usr/share/autoconf/Autom4te/Channels.pm line 59.
BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/Channels.pm line 59.
BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 20.
BEGIN failed--compilation aborted at /usr/bin/autoreconf line 42.

In order to generate the configure script we have to upgrade perl installation - fortunately we can use JoKeR's binary (version 5.8.8).

dev# cd /mnt/C
dev# wget http://mgb111.pradnik.net/addons/soft-lang/perl-5.8.8-080509.tar.bz2
dev# tar xjvf perl-5.8.8-080509.tar.bz2

The old one is itill in front of the PATH sequence, now we have to disable the previous one:

dev# perl -v
This is perl, version 5.004_05 built for i686-linux
...
# mv /usr/bin/perl{,-5.004_05}
# ln -s {/mnt/C/sys/bin/,/usr/bin/}perl
# perl -v
This is perl, v5.8.8 built for i386-linux-thread-multi
...

Ok, now we are ready to proceed with the build process:

# autoreconf -vif
# ./configure --prefix=/mnt/C/sys
# make
# make install

libmikmod-3.2.0-beta2

[Home page]

Build results: [binary] [list files]

Build sequence:

dev# cd /usr/local/src
dev# wget http://mikmod.raphnet.net/files/libmikmod-3.2.0-beta2.tar.bz2
dev# tar xjvf libmikmod-3.2.0-beta2.tar.bz2
dev# cd libmikmod-3.2.0-beta2
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

WMU-6500FS - xml stuff

2008-06-18T17:50:00.007+02:00

xmlto 0.0.20

Build results: Not actually deployed to the box, just built as an Xorg dependency...

Dependencies: [sgml-base 1.26] [docbook-xsl-1.74] [docbook-xml-4.2]

Build sequence:
I think it is not necessary to deploy xmlto to the box, co will configure it locally (it will not go to the /mnt/C/sys directory).

dev# wget http://cyberelk.net/tim/data/xmlto/stable/xmlto-0.0.20.tar.bz2
dev# tar xjvf xmlto-0.0.20.tar.bz2
dev# cd xmlto-0.0.20
dev# ./configure
dev# make
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
...
Variable $SGML_CATALOG_FILES not set

It seems there is no support for XML catalogs on the system. According to this source we can fix it in a following way:

dev# mkdir -p /usr/local/etc/xml
dev# xmlcatalog --noout --create /usr/local/etc/xml/catalog
dev# mkdir -p /usr/local/share/docbook/xsl
dev# cd /usr/local/share/docbook/xsl
dev# wget
"http://downloads.sourceforge.net/docbook/docbook-xsl-1.74.0.tar.bz2?modtime=1212403365&big_mirror=0"
-O docbook-xsl-1.74.tar.bz2
dev# tar xjvf docbook-xsl-1.74.tar.bz

I would have liked to install it in /usr/local/etc, but according to the source only /etc works

dev# mkdir -p /etc/xml
dev# xmlcatalog --noout --add 'nextCatalog' '' 'file:///usr/local/share/docbook/docbook-xsl-1.73.2/catalog.xml' --create /etc/xml/catalog

Now it is time to install the catalog:

dev# cd /usr/local/share/docbook/xsl/docbook-xsl-1.74.0/
dev# ./install.sh
WARNING: This install script is meant to be run as a non-root
         user, but you are running it as root.

Are you sure you want to continue? [No] Y
...
Create /root/.resolver/CatalogManager.properties file? [Yes] Y
...
Add /etc/xml/catalog to /root/.resolver/CatalogManager.properties? [Yes] Y
...
Add /usr/local/share/docbook/xsl/docbook-xsl-1.74.0/catalog.xml
to /root/.resolver/CatalogManager.properties file? [Yes] Y
...
To source your shell environment for this distribution, type the
following:
. /usr/local/share/docbook/xsl/docbook-xsl-1.74.0/.profile.incl
dev# . /usr/local/share/docbook/xsl/docbook-xsl-1.74.0/.profile.incl

Now back to the xmlto installation:

dev# cd /usr/local/src/xmlto-0.0.20
dev# make clean
dev# ./configure
dev# make
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
/usr/local/src/xmlto-0.0.20/./doc/xmlif.xml:4: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

There is a progress, but we are not done withe XML catalogs yet:

dev# cd /usr/local/share/docbook
dev# wget http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip

There is a bug in the busybox version of unzip - for details see this message.
As a workaround we can pre-create the directories before the actual unzipping:

dev# mkdir -p docbook-xml-4.2/ent
dev# unzip docbook-xml-4.2.zip -d docbook-xml-4.2

Now we can register the new XML catalog:

dev# xmlcatalog --noout --add nextCatalog '' file:///usr/local/share/docbook/docbook-xml-4.2/catalog.xml --create /etc/xml/catalog

And finally finish the xmlto installation:

dev# cd /usr/local/src/xmlto-0.0.20
dev# make clean
dev# ./configure
dev# make
dev# make install

libxslt - 1.1.22

Build results: [binary] [list files]

Dependencies: [libxml2-2.6.30]

Build sequence:

dev# cd /ust/local/src
dev# wget ftp://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/libxslt-1.1.22.tar.bz2
dev# tar xjvf libxslt-1.1.22.tar.bz2
dev# cd libxslt-1.1.22
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

libxml2 2.6.30

Build results: [binary] [list files]

Build sequence:

dev# wget ftp://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.30.tar.bz2
dev# tar xjvf libxml2-2.6.30.tar.bz2
dev# cd libxml2-2.6.30
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

sgml-base 1.26

Build results: Not actually deployed to the box

Build sequence:

dev# cd /usr/local/src
dev# wget http://ftp.de.debian.org/debian/pool/main/s/sgml-base/sgml-base_1.26.tar.gz
dev# tar xzvf sgml-base_1.26.tar.gz
dev# cd sgml-base-1.26
dev# make
dev# make install

WMU-6500FS - file 4.24 (unix command)

2008-06-18T15:11:00.004+02:00

Build results: [binary] [list files]

Home page

Build sequence:

dev# wget ftp://ftp.astron.com/pub/file/file-4.24.tar.gz
dev# tar xzvf file-4.24.tar.gz
dev# cd file-4.24
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

WMU-6500FS - m4 1.4.11

2008-06-18T13:47:00.006+02:00

Build results: Not actually deployed to the box

Build sequence:

dev# wget http://ftp.gnu.org/gnu/m4/m4-1.4.11.tar.bz2
dev# tar xjvf m4-1.4.11.tar.bz2
dev# cd m4-1.4.11
dev# ./configure
dev# make
dev# make install

Xorg configure looks directly to /usr/bin, it can probably be re-configured, but I do not want to solve it correctly now, here is a workaround I have used:

dev# ln -s /usr/local/bin/m4 /usr/bin

WMU-6500FS - lsof 4.78

2008-06-14T21:54:00.009+02:00

Build results: [binary] [files list]

In the Web UI there is a possibility to create/delete/resize/format individual disk partitions (WebUI/Storage configuration/Disk utility) however sometimes it is not possible, e.g. format operation fails with error "Device is busy".
It seems there is some process using the drive (holding some file handles or so). The lsof command (meaning "LiSt Open Files") is a tool which can be used to determine what files are being held by which processes.

Info sources: [Device is busy error] [lsof tool] [Vic Abell's Home Page]

Build sequence:
Download and extract:

dev# wget ftp://ftp.cert.dfn.de/pub/tools/admin/lsof/lsof_4.78.tar.gz
dev# tar xzvf lsof_4.78.tar.gz
dev# cd lsof_4.78
dev# tar xvf lsof_4.78_src.tar
dev# cd lsof_4.78_src

Configure settings
(I left all default values, it is here just for you to see what the possible settings are).

dev# ./Configure linux
Do you want to take inventory (y|n) [y]? y
Do you want to customize (y|n) [y]? y
Customizing ...
Enable HASSECURITY (y|n) [n]?
Disable WARNINGSTATE? (y|n) [n]?
Enable HASKERNIDCK (y|n) [n]?
Do you want to rename machine.h to machine.h.old and replace it with
new_machine.h (y|n) [y]? y
dev# make

In order to find what processes hold a file on the C partition, you can use the following command:

box# lsof | grep mnt/C

WMU-6500FS - cvstrac 2.0.1

2008-06-13T22:23:00.008+02:00

Build results: [binary] [files list]
Info sources: [cvstrac site] [cvstrac colored diffs]

Build sequence:

dev# cd /usr/local/src
dev# wget http://www.cvstrac.org/cvstrac-2.0.1.tar.gz
dev# tar xzvf cvstrac-2.0.1.tar.gz
dev# cd cvstrac-2.0.1
dev# cp linux-gcc.mk Makefile

Customize Makefile
(build dir need not be necessary the same as source dir, you have to alter SRCDIR accordingly. Also the INSTALLDIR can be for example set to /mnt/C/sys/var/www/cgi-bin in case you want to run it as CGI)

dev# nano Makefile

SRCDIR = .

INSTALLDIR = /mnt/C/sys/bin

If you have not set the include and lib directories to sys you have to modify also the main.mk:

dev# nano main.mk

XTCC = $(TCC) $(CFLAGS) -I. -I$(SRCDIR) -I/mnt/C/sys/include

$(TCC) -o $(APPNAME) $(OBJ) $(LIBSQLITE) -L/mnt/C/sys/lib

Make the application

dev# make

Error
Undefined reference to sqlite3StrICmp and similar symbols. It seems that 2.0.1 release used a non-public part of SQLite interface and in a recent version of SQLite the referenced functions disappeared.
Fortunately there is a patch 2.0.1-3 solving the problem:

dev# cd ..
dev# wget http://ftp.de.debian.org/debian/pool/main/c/cvstrac/cvstrac_2.0.1-3.diff.gz
dev# gunzip cvstrac_2.0.1-3.diff.gz
dev# patch -p0 < cvstrac_2.0.1-3.diff
dev# cd cvstrac-2.0.1

Or alternatively you can download the development version directly from their CVS:

dev# cvs -d :pserver:anonymous@cvstrac.org:/cvstrac login
dev# cvs -d :pserver:anonymous@cvstrac.org:/cvstrac checkout cvstrac

When prompted for a password, enter "anonymous". For more info see [cvstrac download].

We are ready to build all the three available variants:

dev# make
dev# make install
dev# make APPNAME=svntrac
dev# make install APPNAME=svntrac
dev# make APPNAME=gittrac
dev# make install APPNAME=gittrac

Now we have the application(s) installed and can launch it. Root can neither initialize a project nor launch the server (actually it is possible but you have to launch it in chroot jail), for more info see [installation] and [chroot jail].

dev# su <user>
dev# gittrac init /mnt/C/sys/var/git <project>
dev# gittrac server 8008 /mnt/C/sys/var/git/ <project> &

WMU-6500FS - Boost 1.35

2008-06-10T22:54:00.006+02:00

Build results: [binary] [files list]
Note: besides the DSO files this archive contains even all the boost header files and documentation (not actually necessary on the box).

Build sequence:

dev# wget http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206795398&big_mirror=0
dev# tar xjvf boost_1_35_0.tar.bz2
dev# cd boost_1_35_0
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

The boost library names are more specific (contain boost version and compiler version) than some software demand. I do not know whether there should be libboost_*-mt.so symlinks, maybe I have not configured boost library properly, as a quick fix I have created the links manually:

dev# cd /mnt/C/sys/lib
dev# for i in `ls ./libboost_*-gcc33-mt-1_35.so.1.35.0`; do ln -s `basename $i` ${i/%-gcc33-mt-1_35.so.1.35.0/-mt.so}; done

WMU-6500FS - GIT 1.5.5.3

2008-06-09T09:31:00.023+02:00

Build results: [binary] [files list]

Build sequence:

dev# wget http://kernel.org/pub/software/scm/git/git-1.5.5.3.tar.gz
dev# tar xzvf git-1.5.5.3.tar.gz
dev# ./configure --prefix=/mnt/C/sys
dev# make
dev# make install

Deployment hack
(touch some files in order to include them to the package)

dev# find /mnt/C/sys/share/ -path "*git*" -type f -exec touch {} \;
dev# find /mnt/C/sys/lib/ -path "*Git*" -type f -exec touch {} \;

Transfer Subversion DB to GIT
Dependencies: subversion
Info source: [git-svn intro]

box# svnserve -d -r /mnt/C/sys/var/svn/<project>
box# cd /mnt/C/sys/var/git/<project>
box# git svn init -t tags -b branches -T trunk svn://localhost/<project>
(or simply: box# git svn init svn://localhost/<project> )
box# git svn fetch

Error 1

perl: Can't resolve symbol 'apr_initialize'

can be replicated as follows:

box# perl -e "use SVN::Core"

Inspect dependencies:

dev# ldd /mnt/C/sys/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/SVN/_Core/_Core.so
...
libapr-1.so.0 => /mnt/C/sys/apache2/lib/libapr-1.so.0 (0x00000000)
...
dev# nm /mnt/C/sys/apache2/lib/libapr-1.so.0 | grep apr_initialize
00013c18 T apr_initialize

Everything seem to be ok, maybe the libraries are loaded in a wrong order...

# export LD_PRELOAD=/mnt/C/sys/apache2/lib/libapr-1.so.0

... error 1 fixed, but there is one more ...
Error 2

perl: Can't resolve symbol 'svn_swig_pl_get_current_pool'

can be replicated as follows:

box# perl -e "use SVN::Wc; SVN::Wc::adm_open3(undef, '.', 0, 0);"

Another pre-load needed:

box# export LD_PRELOAD=$LD_PRELOAD:/mnt/C/sys/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/SVN/_Core/_Core.so

Problem fixed - not saying that the fix is a proper solution, but I use the export only for repo conversion.