WMU-6500FS - Deluge torrent (part III)

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.