[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libgtk+2.0-directfb question

Frans Pop wrote:
On Saturday 08 October 2005 15:36, Attilio Fiandrotti wrote:

in the last days i've been trying to understand why gtk.so crashes
inside the miniiso using Alastair's libgtk+-directfb udeb.
Today i unpacked libgtk+2.0-directfb0-udeb_2.0.9.2-3_i386.udeb contsnt
inside /gtkudeb and ,as root i did

I have also run some tests. These tests were done:
- using the last frontend Attilio made available;
- using Alastair's libgtk+2.0-directfb0-udeb
- without the libc that is currently in the root tarball

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
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.

In all my tests strange fonts are still not shown.

some more reportd from my today's tests i hope may be useful: if i compile a simple "ghello" application against official/my own libs then i test the so ontained binary using libraries from libgtk+2.0-directfb0-udeb ghello runs correctly. If i pack ghello inside a ghello.tgz and include it inside the miniiso then, whin i try to run ghello from inside thw miniiso i get the error reported in


(the same error applies to functions getresuid, getresgid, getgid, setpgid).
Since it seemed to me symbols were missing from libc i included the following (never really called) funcion inside gtk.c to see if this time the missing symbols were force-included inside libc

void dummy_function(void)
		setpgid(NULL, NULL);

this time previously missing symbols were included since ghello returned with the following error message (strace output)


so , it seems sometimes libc do not contains some needed functions and you have to explicitly force symbols to be included inside it.

Another test i've done: as i told you before i've unpacked libgtk+2.0-directfb0-udeb inside /gtkudeb on my debian system and gtk.so ran fine togheter with those libraries no matter what set of libraries was compiled against. Then i tried to unpack inside /gtkudeb also the contents of libdirectfb-0.9-22-udeb_0.9.22-7.1_i386.udeb so that libraries from that udeb were used instead of those from libdirectfb-0.9-22.deb installed on my system. The gtk.so crashed as any other gtkdfb app: it seems that libdirectfb-0.9-22-udeb_0.9.22-7.1_i386.udeb and libgtk+2.0-directfb0-udeb behave badly if used togheter, any idea why this happens?

davide also told me that fjp has discovered gtk.so works fine with standard udebs if ibs are not reduced: this is really good news.



Reply to: