Re: libgtk+2.0-directfb question

[Davide Viti <zinosat@tiscali.it>]

Hi,

> 
> 1. Without library reduction
> I created a modified mklibs that does most of its normal work, but does 
> not actually reduce libraries (instead it just copies them).
> This resulted in a working frontend.
> 
> 2. With library reduction, but copying some full libraries back in
>    afterwards
> I did this by adding something in the Makefile that copies an original 
> library into the tree after the library reduction step.
> - only libc added back in, gives improvement but frontend still crashes;
> - both libc and libm added back in, gives working frontend.

as discussed on IRC, either the library reduction system has a bug or,
more likely, some libraries should declare as needed some symbols.
We now have to find out which library fails to declare as needed which
symbols. 
Since I don't have any spare machine, I need to find a good way to
investigate this; my options are qemu or my real machine.
Last night I was playing with the following idea (fjp thought it was
"creative"):
use the build/tmp/gtk-miniiso/tree directory created during the build of
mini.iso as filesystem for a chroot.
Using it I got to the initialization of directfb and the failure (i
supposed) is due to the lack of a framebuffer device on my system).
If anyone were interested in trying it out here's how I did it:

cp /bin/bash  tree/usr/bin
cp /usr/lib/libncurses.so tree/usr/lib/libncurses.so.5
cp /usr/bin/strace tree/usr/bin/

chroot tree /usr/bin/bash
debconf-loadtemplate d-i /var/lib/dpkg/info/*.templates
debconf -f gtk -o d-i /usr/bin/main-menu


Ciao
Davide