Hide Forgot
Description of Problem: LIBTOOL. That's the problem. LIBTOOL. Oh, detail.... LIBTOOL is a PITA. OK, now I've got that outa my system.... Libtool insists on relinking libraries whenever you copy them, build them, install them, talk about them to your friends, type their names in an email.... When doing the 'make install', if there isn't a suitable libqtcmodule.so already installed in the /bla/bla/pythonN.M/site-packages dir, then that file is not found, and the install bombs out. Of course, if there IS one installed, then you're linking against something other than what you just built. This might not be what was intended. Solution: add the buildroot/bla/bla/site-packages dir to the LDFLAGS for the configure run. What else is wrong with this source rpm? 1. %{pythonver} not used everywhere it should be. 2. %{_libdir} not used everywhere it should be. 3. URL for source tarball is out of date 4. Prereqs are not strict enough: python version needs to match %{pythonver} and sip version needs to match PyQt version. Patch will be attached in a few minutes. A patch against his current .spec file (from PyQt-3.0pre2-Qt-2.3.1) has been sent to Phil (owner of code) today, but no response yet.
This bug affects the forthcoming RH7.2 release as well, I would expect.
Created attachment 34061 [details] Patch to address all these issues in the spec file.
cannot reproduce it on my local machine with RHL 7.2. Rebuild PyQt-2.4 fine without installed PyQt/PyQt-devel on my local machine. Perhaps it's only in PyQt-3.0Pre2!
NNope. It's 2.4, 2.5, 3.0pre1, 3.0pre2. Maybe you have a different version of libtool? The fix is to put: LDFLAGS="-L$RPM_BUILD_ROOT%{_libdir}/pythonN.N/site-packages" \ right before configure. This is 100% reproducible for all versions of PyQt from 2.4 to the latest test release, using both Redhat spec file and Phil's spec file. It's broken, all right. I'm using a Rawhide system with newest libtool, and it will not install without the patch above. As I said, 100% reproducible. I'll attach a build log so you can see what's going on.
Ah, crap. I stand corrected. It's 100% reproducible from 2.5 on. 2.4, OTOH, dies a different death. make install-data-hook make[3]: Entering directory `/home/alane/rpm/BUILD/PyQt-2.4/qt' (cd /tmp; PYTHONPATH=/home/alane/rpm/tmp/PyQt-root/usr/lib/python2.2/site-packages:/home/alane/rpm/tmp/PyQt-root/usr/lib/python2.2/site-packages python -O -c "import qt") make[3]: *** [install-data-hook] Error 139 make[3]: Leaving directory `/home/alane/rpm/BUILD/PyQt-2.4/qt' make[2]: *** [install-data-am] Error 2 make[2]: Leaving directory `/home/alane/rpm/BUILD/PyQt-2.4/qt' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/alane/rpm/BUILD/PyQt-2.4/qt' make: *** [install-recursive] Error 1 error: Bad exit status from /home/alane/rpm/tmp/rpm-tmp.95988 (%install) Which doesn't really show you what happened, but: [alane@wwweasel site-packages]$ cd /tmp; PYTHONPATH=/home/alane/rpm/tmp/PyQt-root/usr/lib/python2.2/site-packages:/home/alane/rpm/tmp/PyQt-root/usr/lib/python2.2/site-packages python -O -c "import qt" Segmentation fault [alane@wwweasel tmp]$ Try building 2.5 and see where you get. And yes, it does look libtool related.
which version of libtool and automake ar installed on your build machine?
[alane@wwweasel alane]$ rpm -q libtool automake autoconf libtool-1.4-8 automake-1.5-1 autoconf-2.52-3 [alane@wwweasel alane]$ The way it happens is, at the end, the make install tries to relink, and uses the final (real) destination path in the -L option, not the DESTDIR= path. But if you have an acceptable libqtcmodule.so already there, it'll pick it up.