Bug 101077 - Qt library could not be found when compiling SIP . . .
Summary: Qt library could not be found when compiling SIP . . .
Status: CONFIRMED
Alias: None
Product: bindings
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kde-bindings
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-08 07:42 UTC by Jason Flatt
Modified: 2021-03-09 05:24 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
proper qt_dir definition (1.76 KB, patch)
2006-03-01 23:24 UTC, Hai Zaar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Flatt 2005-03-08 07:42:54 UTC
Version:           3.4.0-rc1 (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
Compiler:          gcc (GCC) 3.3.3 GNU Make 3.80 ; automake (GNU automake) 1.9.5
OS:                Linux

When compiling kdebindings on my Linux distribution, Source Mage, I get the following output when it gets to the python area:

[snip]
Making all in python
make[3]: Entering directory `/usr/src/kdebindings-3.4.0/python'
mkdir sip
mkdir: cannot create directory `sip': File exists
make[3]: [sipdone] Error 1 (ignored)
export builddir=`pwd` ; \
cd ./sip ; \
export QTDIR=/usr/include/ ; \
/usr/bin/python configure.py -b /usr/bin -d /usr/lib/python2.3/site-packages 
-e `echo -I/usr/include/python2.3 | sed s/-I//` -l qt-mt -v /usr/share/sip/ 
-t
"$builddir/sip" INCDIR_QT=/usr/include/qt
Error: The qt-mt Qt library could not be found in /usr/include//lib.
This is SIP 4.1.1 for Python 2.3 on linux2.
make[3]: *** [sipdone] Error 1
make[3]: Leaving directory `/usr/src/kdebindings-3.4.0/python'
make[2]: make[2]: Leaving directory `/usr/src/kdebindings-3.4.0'
*** [all-recursive] Error 1
make[1]: make[1]: Leaving directory `/usr/src/kdebindings-3.4.0'
*** [all] Error 2


If you'll notice, it is exporting QTDIR=/usr/include/, which is the wrong directory (it should be /usr), and then tries to find the libraries in /usr/include//lib.

Where I believe the problem lies is line 8 of python/Makefile.am:
qt_dir = $(dir @qt_includes@)

On my system, that translates to QTDIR==/usr/include/.  When the compile gets to line 28 in python/Makefile.am, the library path is set to /usr/include//lib, which, of course, is incorrect.

When I set line 8 of python/Makefile.am to qt_dir = /usr (and re-ran aclocal, because I have a newer version of automake installed), the compile completed correctly.

I'm not sure what the correct setting is that needs to be on line 8, because I tried several that all failed.  Only when I hard-coded the path did it actually succeed.  I'm sure that's not the correct answer, but I'm sure that you all who know the internals of KDE so much better than I do, will be able to come up with the correct answer.

BTW, I am running 3.4.0-rc1, but I checked CVS HEAD before submitting this bug report, and this problem is still there.
Comment 1 Jason Flatt 2005-03-10 05:12:59 UTC
Okay, I found a setting that seemed to work correctly for me.  Setting line 8 of python/Makefile.am to this:

qt_dir = ${QTDIR}

gave me the correct variable settings and allowed kdebindings to continue building.
Comment 2 Jason Flatt 2005-03-10 05:28:07 UTC
Hmm, I thought I should mention that this bug is in the current stable version of kdebindings as well.
Comment 3 Hai Zaar 2006-03-01 23:24:11 UTC
Created attachment 14922 [details]
proper qt_dir definition

Same here. 
I think the proper way to fix it is to AC_SUBST qt_dir from configure (together
with qt_includes and qt_libs) and then setting
qt_dir = @qt_dir@ 
in Makefile.am

Patch attached.

NOTE: after applying the patch you need to run 'make -f Makefile.cvs'
Comment 4 Hai Zaar 2006-03-01 23:42:14 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Hai Zaar 2006-03-01 23:43:10 UTC
BWT - I'm using kdebindings-3.5.1 + qt-3.3.5
Comment 6 Justin Zobel 2021-03-09 05:24:43 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.