[PyKDE] PyQt - undefined symbol

[Erik Dahlgren]

This is probably the problem. Turned out that had python-2.2.2-26 but 
python-devel-2.2.2-11. Don't know how I missed that during the upgrade. 
Anyway, now the versions match and I am recompiling everything, so hopefully 
everything will work after that. I will give you an update when it is done.

Erik

On Saturday 19 April 2003 07:37 pm, Jim Bublitz wrote:
> On 19-Apr-03 Erik Dahlgren wrote:
> > I looked a little closer at the nm output of libpython2.2.a and
> > found
> >
> >          U PyUnicodeUCS2_FromUnicode
> > 00000440 T PyUnicodeUCS2_FromUnicode
> >          U PyUnicodeUCS2_FromUnicode
> >
> > So it is defined. Any idea why libqtcmodule.so can't find it
> > then?
>
> I got this whole thing off on a wrong tangent in some respects.
> There are basically 4 things that relate to the UCS2/UCS4
> distinction: python (the executable), libpython.a, Python.h and
> libqtcmodule.so. libpython.a is actually unimportant in most
> respects. libqtcmodule.so gets its symbols via Python.h; the
> python executable gets it symbols from the Python source files when
> compiled, so if Python.h is not from the same set of source files
> as python itself, you'll have a mismatch.
>
> My best guess is that RH has two packages: python*.rpm and
> python-devel*.rpm. The python executable is probably in the first,
> and libpython and Python.h are in the second. If you upgrade one
> but not the other, you'd have a mismatch (or if RH built the two
> packages inconsistenly it'd be the same).
>
> When you *build* PyQt, it looks for Python symbols in Python.h.
> When you *import* PyQt, PyQt tries to resolve the Python symbols
> from the interpreter's set of symbols, and in this case fails
> because they're a different set.
>
> My mistake (one of several) was to have you treat libpython.a as if
> it were a .so file loaded by python - it's not. There is the
> equivalent of libpython.a statically linked into the interpreter,
> but it may not be the same libpython.a that you can run nm on.
> There isn't any way to tell for sure, because your python has its
> symbols stripped. All we established is that libpython.a and
> Python.h are consistent, which is meaningless in this case.
>
> The two possible solutions are: a) find a python-devel*.rpm package
> that matches your python*.rpm package; b) get a complete source
> package (eg from python.org) which includes a consistent set of all
> components and compile it on your machine. The tarball from
> python.org will contain all the components that the two rpms would
> contain (and maybe more if RH does a python-devel-doc*.rpm  pkg
> too). You'll need to rebuild sip and PyQt from scratch too, so they
> no longer contain the inconsistent symbols. Be sure to get Python
> 2.2.x and *not* 2.3.
>
> Sorry for the mixup - it's the first time I've seen this happen.
>
> Jim

-- 
Erik Dahlgren
ebdahlgr at unity.ncsu.edu

"Programming today is a race between software engineers 
striving to build bigger and better idiot-proof programs, 
and the Universe trying to produce bigger and better idiots. 
So far, the Universe is winning."