Re: [pygtk] Pygtk themes.
If you are grabbing this stuff out of CVS, you should probably switch over to the stable branches of glib and gtk+ (I think they are named glib-1-2 and gtk-1-2). With gtk+-1.3, they are back to development and have started changing things around (AFAIK, imlib and GNOME are staying on the gtk 1.2 branch until gtk 1.3 has stabilised a bit). James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 27 Feb 1999, Michael Hudson wrote: On Sat, 27 Feb 1999, James Henstridge wrote: That is a truely wierd problem. May I ask what versions of glib, gtk+, imlib, gtk-engines and pygtk you are using? Fresh from CVS: [mwh21@atrus mwh21]$ glib-config --version 1.3.0 [mwh21@atrus mwh21]$ gtk-config --version 1.3.0 [mwh21@atrus mwh21]$ imlib-config --version 1.9.4 I just tested it out on my system and it worked like a charm (I have CVS versions from a few days ago). It's not been working for a few days. I'm not sure pygtk has worked since gtk started autoreading ~/.gtkrc. It doesn't seem to get along with the pixmap theme. The next thing that might be causing your problem is that the imlib don't have the shared library dependencies built into them. What happens if you run "ldd /opt/gnome/lib/libgdk_imlib.so.1" does it display the libraries it should be linking with (libgmodule, libglib, libdl). [mwh21@atrus mwh21]$ ldd /opt/gnome/lib/libgdk_imlib.so libgmodule-1.3.so.0 = /opt/gnome/lib/libgmodule-1.3.so.0 (0x40027000) libglib-1.3.so.0 = /opt/gnome/lib/libglib-1.3.so.0 (0x4002a000) libdl.so.2 = /lib/libdl.so.2 (0x4004b000) libc.so.6 = /lib/libc.so.6 (0x4004e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x) That looks OK to me... What version of libtool did you use to compile imlib? (you can check by going to the build directory and typing ./libtool --version). If it is less than 1.2d that would be your problem. Well it was vanilla 1.2, but I've updated, recompiled glib, gtk+, imlib and gnome-python, and it still cores. Further poking seems to indicate that the pixmap module is loaded twice - the first time it fails with the unresolved symbol error, and then it's tried again, and it dumps core when g_module_open calls its check_module_init function... The problem is gdb can't seem to follow execution through tha function pointer call so I don't know what's going on there. I don't know enough about the process of symbol resolution to guess a solution. Anybody got any ideas? If you aren't using a i386 linux system, try copying the libtool, ltmain.sh and libtoolize scripts from a recent gtk+ to the imlib and gtk-engines packages and rebuilding. No it's a fairly ordinary RedHat 5.2 install on an i686, kernel version 2.0.36. James Henstridge. Thank you far your help... Shared libraries are weird aren't they? Michael Hudson Jesus College Cambridge [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Pygtk themes.
That is a truely wierd problem. May I ask what versions of glib, gtk+, imlib, gtk-engines and pygtk you are using? I just tested it out on my system and it worked like a charm (I have CVS versions from a few days ago). The next thing that might be causing your problem is that the imlib don't have the shared library dependencies built into them. What happens if you run "ldd /opt/gnome/lib/libgdk_imlib.so.1" does it display the libraries it should be linking with (libgmodule, libglib, libdl). What version of libtool did you use to compile imlib? (you can check by going to the build directory and typing ./libtool --version). If it is less than 1.2d that would be your problem. If you aren't using a i386 linux system, try copying the libtool, ltmain.sh and libtoolize scripts from a recent gtk+ to the imlib and gtk-engines packages and rebuilding. James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 26 Feb 1999, Michael Hudson wrote: I get a core dump whenever I start a pygtk app, looking something like Gtk-WARNING **: /opt/gnome/lib/libgdk_imlib.so.1: undefined symbol: gdk_display Segmentation fault (core dumped) Looking at the start of gdb's traceback I get this: #0 0x1232 in ?? () #1 0x4000d018 in g_module_open ( file_name=0x81dd5d0 "/opt/gnome/lib/gtk/themes/engines/libpixmap.so", flags=0) at gmodule.c:266 #2 0x4041a7e8 in gtk_theme_engine_get (name=0x81dc8e0 "pixmap") at gtkthemes.c:89 #3 0x403f8240 in gtk_rc_parse_engine (scanner=0x81db380, rc_style=0x81dd498) at gtkrc.c:1626 #4 0x403f7b07 in gtk_rc_parse_style (scanner=0x81db380) at gtkrc.c:1323 #5 0x403f7762 in gtk_rc_parse_statement (scanner=0x81db380) at gtkrc.c:1177 #6 0x403f703f in gtk_rc_parse_any ( input_name=0x81db298 "/home/mwh21/.themes/marble3D/gtk/gtkrc", input_fd=7, input_string=0x0) at gtkrc.c:899 So it would seem to be the pixmap theme at fault; sure enough if I remove ~/.gtkrc, everything works. All the other gtk+/gnome apps work just fine. Any ideas? STOP PRESS! Further experimenting leads me to find that prepending LD_PRELOAD=" /opt/gnome/lib/libgdk.so /opt/gnome/lib/libglib.so /opt/gnome/lib/libgtk.so " to the command line stops the crashes... So what must be happening is that the pixmap theme needs symbols from some other libraries before they've been loaded. That this result is a core dump sucks, but never mind. I've tried playing around with the link options of _gtkmodule.so, but with no success. I seem to remember that an appropriately named file in the same directory as an extension module can be used to provide libraries that should be loaded before that extension module, but can't find mention of it in the current documentation. PS: Everything is very new; python, gnome-python and gtk+ all from CVS. Michael Hudson Jesus College Cambridge [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
