Bug 136377 - configure doesn't detect libqt-mt correctly in fedora/redhat 64bit
Summary: configure doesn't detect libqt-mt correctly in fedora/redhat 64bit
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: 3.5
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-27 11:17 UTC by Kerwin Khu
Modified: 2007-12-21 11:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
add default fedora/redhat qt locations, adding pkg-config support (1.96 KB, patch)
2007-12-20 15:36 UTC, Rex Dieter
Details
add default fedora/redhat qt locations, adding pkg-config support (take 2) (1.95 KB, patch)
2007-12-20 22:14 UTC, Rex Dieter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kerwin Khu 2006-10-27 11:17:01 UTC
Version:           2.7.5 (using KDE KDE 3.5.5KDE 1.2)
Installed from:    Compiled From SourcesCompiled From Sources
Compiler:          gcc 3.4.6 
OS:                Linux

This appears to be a bug in the configure script for some platforms. I encountered this problem when compiling yakuake-2.7.5 on CentOS 4.4 x86_64

This was the error message after running ./configure :

configure:30161: error: Qt (>= Qt 3.2 and < 4.0) (library qt-mt) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Make sure that you have compiled Qt with thread support!

Apparently, libqt-mt could not be found. On going through config.log, I noticed this line:

tried /usr/lib64/qt-3.3/lib64

But, on my system, the Qt libraries were at /usr/lib64/qt-3.3/lib instead.

It may be due to non-standard placement of the Qt libraries for CentOS (and thus RHEL, and maybe Fedora Core too). In any case, I fixed it by adding $dir/lib to the directories searched by the configure script for Qt


@@ -30010,7 +30010,7 @@ ac_qt_includes="$qt_incdir"
 
 qt_libdirs=""
 for dir in $kde_qt_dirs; do
-   qt_libdirs="$qt_libdirs $dir/lib${kdelibsuff} $dir"
+   qt_libdirs="$qt_libdirs $dir/lib${kdelibsuff} $dir/lib $dir"
 done
 qt_libdirs="$QTLIB $qt_libdirs /usr/X11R6/lib /usr/lib /usr/local/qt/lib $x_libraries"
 if test ! "$ac_qt_libraries" = "NO"; then


This patch works for my x86_64 system. I think the problem could also be resolved by using --with-qt-libraries switch, but this way seems easier for other prospective users.
Comment 1 Rex Dieter 2006-10-28 14:23:18 UTC
CentOS includes /etc/profile.d/qt.sh which should properly set QTLIB env var for your platform.
Comment 2 Rex Dieter 2006-10-28 14:31:56 UTC
OK, looks like redhat hasn't fixed that yet... see also:
"define QTINC/QTLIB in qt.sh/qt.csh": http://bugzilla.redhat.com/212722
Comment 3 Eike Hein 2007-10-05 15:10:55 UTC
I'll leave that to downstream, then.
Comment 4 Rex Dieter 2007-12-06 18:19:14 UTC
I'd really like this to get fixed properly, so fedora/redhat derivatives just work.
Comment 5 Rex Dieter 2007-12-06 18:31:06 UTC
In short I'd like to see at least:

Index: acinclude.m4.in
===================================================================
--- acinclude.m4.in     (revision 745636)
+++ acinclude.m4.in     (working copy)
@@ -1459,7 +1459,7 @@

 qt_libdirs=""
 for dir in $kde_qt_dirs; do
-   qt_libdirs="$qt_libdirs $dir/lib${kdelibsuff} $dir"
+   qt_libdirs="$qt_libdirs $dir/lib${kdelibsuff} $dir/lib $dir"
 done
 qt_libdirs="$QTLIB $qt_libdirs /usr/X11R6/lib /usr/lib /usr/local/qt/lib $x_libraries"
 if test ! "$ac_qt_libraries" = "NO"; then


It also would make sense to me to add pkgconfig support for detecting qt (and I'd be willing to work on that), if there are no objections.
Comment 6 Rex Dieter 2007-12-20 15:36:27 UTC
Created attachment 22631 [details]
add default fedora/redhat qt locations, adding pkg-config support
Comment 7 Rex Dieter 2007-12-20 16:56:28 UTC
Seems I don't have sufficient mojo/Karma to commit this myself, reassigning back to default owner.
Comment 8 David Faure 2007-12-20 20:30:48 UTC
OK I'll commit this patch; but I think I found a bug in it...

+  if (`$PKG_CONFIG --exists qt-mt`) ; then
This opens a sub-shell and calls --exist in it, and only keeps the string output of it; I don't think this works. For proof:
(`pkg-config --exists idontexist`) && echo ok
shows ok.

I think this should be simply:
if $PKG_CONFIG --exists qt-mt; then
no?
Comment 9 Rex Dieter 2007-12-20 20:45:43 UTC
Hmm... you may very well be right, dang, that's one conditional that I didn't test very well (ie, qt-mt.pc not existing).

I just lifted similar code from elsewhere in acinclude.m4.in in the OpenEXR detection bits, so that's likely wrong too.  Look for:
if !(`$PKG_CONFIG --exists OpenEXR`) ; then
:)
Comment 10 David Faure 2007-12-20 21:10:48 UTC
SVN commit 750986 by dfaure:

This was bogus indeed.
CCBUG: 136377


 M  +2 -2      acinclude.m4.in  


WebSVN link: http://websvn.kde.org/?view=rev&revision=750986
Comment 11 Rex Dieter 2007-12-20 22:14:38 UTC
Created attachment 22639 [details]
add default fedora/redhat qt locations, adding pkg-config support (take 2)

updated patch using better
if $PKG_CONFIG --exists ... ; then
contructs
Comment 12 David Faure 2007-12-21 11:16:46 UTC
SVN commit 751182 by dfaure:

Committing patch by Rex Dieter: add default fedora/redhat qt locations, adding pkg-config support
BUG: 136377


 M  +26 -2     acinclude.m4.in  


WebSVN link: http://websvn.kde.org/?view=rev&revision=751182