Stephen Watson wrote:

I have just compiled and installed pygtk 1.99.14 on Solaris 8, and it's
broken. Running one of the examples I get:

buster:~/src/pygtk-1.99.14/examples/simple python simple.py Traceback (most recent call last):
File "simple.py", line 7, in ?
import gobject, gtk
ImportError: ld.so.1: python: fatal: relocation error: file /usr/local/lib/python2.2/site-packages/gtk-2.0/gobjectmodule.so: symbol glib_micro_version: referenced symbol not found

Checking with ldd:

buster:~/src/pygtk-1.99.14 ldd .libs/gobjectmodule.so
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1

Comparing with the previous (working) version:

buster:~/src/pygtk-1.99.14/examples/simple ldd ../../../pygtk-1.99.13/.libs/gobjectmodule.so libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1

So the module is not being built with the correct libraries. Rechecking the
output from ./configure I find:

checking for GLIB - version >= 2.0.0... yes (version 2.0.7)
First RE may not be null
checking for atk >= 1.0.0... yes
checking ATK_CFLAGS... -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include checking ATK_LIBS... -L/usr/local/lib -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 First RE may not be null
checking for pango >= 1.0.0... yes
checking PANGO_CFLAGS... -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include checking PANGO_LIBS... -L/usr/local/lib -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 First RE may not be null
checking for pkg-config... (cached) /usr/local/bin/pkg-config
checking for GTK+ - version >= 2.0.0... yes (version 2.0.9)
First RE may not be null

And in the relevant part of configure.in:

dnl get rid of the -export-dynamic stuff from the configure flags ...
export_dynamic=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh`
dnl glib
AM_PATH_GLIB_2_0(glib_required_version,,[AC_MSG_ERROR(maybe you want the gtk-gnome-1-2 branch?)],gobject $extra_mods)
GLIB_LIBS=`echo $GLIB_LIBS | sed -e "s/$export_dynamic//"`

But when I run libtool --config I get:

buster:~/src/pygtk-1.99.14 ./libtool --config | grep export_dynamic
export_dynamic_flag_spec=""

And sure enough:

buster:~/src/pygtk-1.99.14 sed -e s///
First RE may not be null

And in the generated Makefile I find

GLIB_LIBS =

I have reverted to 1.99.13.

Thanks for the bug report. I will fix it in the next release. (that is, check if the export-dynamic flag is empty). The reason for that code change is that specifying -export-dynamic when linking a shared library causes all its symbols to be exported, even if a version script has been used to limit the exported symbols (which I do with pygtk, to reduce the likelyhood of symbol conflicts with other loaded modules, and improve startup time marginally).

James.

--
Email: [EMAIL PROTECTED] | Linux.conf.au http://linux.conf.au/
WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia.


_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Reply via email to