Bug 54627 - Source RPM will not build without an installed PyQt on build system
Summary: Source RPM will not build without an installed PyQt on build system
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: PyQt   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-14 09:03 UTC by j. alan eldridge
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-14 09:06:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to address all these issues in the spec file. (1.74 KB, patch)
2001-10-14 09:06 UTC, j. alan eldridge
no flags Details | Diff

Description j. alan eldridge 2001-10-14 09:03:46 UTC
Description of Problem:

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.

Comment 1 j. alan eldridge 2001-10-14 09:04:48 UTC
This bug affects the forthcoming RH7.2 release as well, I would expect.

Comment 2 j. alan eldridge 2001-10-14 09:06:12 UTC
Created attachment 34061 [details]
Patch to address all these issues in the spec file.

Comment 3 Ngo Than 2001-10-16 18:58:22 UTC
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!

Comment 4 j. alan eldridge 2001-10-16 23:51:29 UTC
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.

Comment 5 j. alan eldridge 2001-10-17 01:10:11 UTC
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;
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;
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.

Comment 6 Ngo Than 2001-10-17 08:41:54 UTC
which version of libtool and automake ar installed on your build machine?

Comment 7 j. alan eldridge 2001-10-17 17:24:54 UTC
[alane@wwweasel alane]$ rpm -q libtool automake autoconf
[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.

Note You need to log in before you can comment on or make changes to this bug.