Bug 137926 - Cannot make xconfig on x86_64 because of qt (solution)
Cannot make xconfig on x86_64 because of qt (solution)
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: 172303 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-11-02 16:32 EST by Philippe Rigault
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-01 01:41:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Philippe Rigault 2004-11-02 16:32:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
This bug is x86_64 specific.

The standard way to build a kernel with 'make xconfig' conflicts with the way qt is installed on Fedora Core (2 and 3).

As a result, 'make xconfig' fails.

Detailed explaination and solution provided below.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install FC2 or FC3
2. Untar kernel source in standard place (e.g X.Y.Z=2.6.9)
  cd /usr/src
  tar jxf somewhere/linux-X.Y.X.tar.bz2
  cd linux-X.Y.X
3. make xconfig

Actual Results:  # make xconfig
  HOSTLD  scripts/kconfig/qconf
/usr/bin/ld: cannot find -lqt
collect2: ld returned 1 exit status
make[1]: *** [scripts/kconfig/qconf] Error 1
make: *** [xconfig] Error 2

Expected Results:  Target builds, Qt-based graphical configuration window appears.

Additional info:

'make xconfig' fails because the target 'qconf' is not built.
qconf is not built because the *proper* qt (libqt-mt.so) is not found 

The Makefile used to build qconf is scripts/kconfig/Makefile

The relevant part is here:
------------------ BEGIN MAKEFILE PART ------------------ 
$(obj)/qconf.o: $(obj)/.tmp_qtcheck

ifeq ($(qconf-target),1)
MOC = $(QTDIR)/bin/moc
-include $(obj)/.tmp_qtcheck

# QT needs some extra effort...
        @set -e; for d in $$QTDIR /usr/share/qt* /usr/lib/qt*; do \
          if [ -f $$d/include/qconfig.h ]; then DIR=$$d; break; fi; \
        done; \
        if [ -z "$$DIR" ]; then \
          echo "*"; \
          echo "* Unable to find the QT installation. Please make sure that the"; \
          echo "* QT development package is correctly installed and the QTDIR"; \
          echo "* environment variable is set to the correct location."; \
          echo "*"; \
          false; \
        fi; \
        LIBPATH=$$DIR/lib; LIB=qt; \
        $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
          LIBPATH=$$DIR/lib/$$($(HOSTCXX) -print-multi-os-directory); \
        if [ -f $$LIBPATH/libqt-mt.so ]; then LIB=qt-mt; fi; \
        echo "QTDIR=$$DIR" > $@; echo "QTLIBPATH=$$LIBPATH" >> $@; \
        echo "QTLIB=$$LIB" >> $@; \
        if [ ! -x $$DIR/bin/moc -a -x /usr/bin/moc ]; then \
          echo "*"; \
          echo "* Unable to find $$DIR/bin/moc, using /usr/bin/moc instead."; \
          echo "*"; \
          echo "MOC=/usr/bin/moc" >> $@; \
------------------  END  MAKEFILE PART ------------------ 

The Makefile uses the output of `$(HOSTCXX) -print-multi-os-directory` to look for libqt-mt.so.

This output is (on x86_64):
# g++ -print-multi-os-directory

In other words, libqt-mt.so is searched only in:

Directory does not exist => libqt-mt.so not found
Here is what happens at the end of the search for qt:

# more ./scripts/kconfig/.tmp_qtcheck

In detail:
QTDIR=/usr/lib64/qt-3.3 <- Correct
QTLIBPATH=/usr/lib64/qt-3.3/lib/../lib64 <- Directory does not exist, therefore libqt-mt.so cannot be found
QTLIB=qt <- Wrong, should be qt-mt (cannot be found) 

Solution: add the following symlink in qt package:
$(QTDIR)/lib64 -> $(QTDIR)/lib
Comment 1 Ngo Than 2004-11-02 16:46:26 EST
it's a bug in kernel, reassign it to correct component. i remember
that i already sent a fix to Arjan while ago.
Comment 2 Philippe Rigault 2004-11-02 21:41:35 EST
I agree on the real cause (it is indeed a bug in kernel, mainline 
kernel even), but still recommend you "fix" Qt (modify/patch would be 
more appropriate, since it is not broken) for now, to avoid the loss 
of a very important functionality (compiling a kernel from 
Fedora Core users do not care in which component the bug is, what 
matters is that things are not "broken" (from the user's point of 
view). Since Arjan cannot fix mainline kernels, the only safe thing 
to do is guarantee from the Qt side that vanilla kernels will 
compile. I do not consider that fixing only Fedora Core kernels would 
be enough, given the large numbers of people using vanilla kernels. 
The place to fix it would be bugzilla.kernel.org. I have not seen 
anything related to it there. Do you want me to file a bug there ? 
(Or, since you have a fix, could you file it yourself ?) 
The Qt fix I suggest carries a near-zero risk as far as I can see. If 
mainline kernel fixes the bug, we'll end up with a useless symlink, 
that's all. You will be able to remove it as soon as mainline kernels 
are OK. 
Comment 3 Dave Jones 2004-11-02 22:23:15 EST
the ideal situation is for this to get fixed in the mainline kernel,
and have that propagate back into Fedora naturally.
Comment 4 Philippe Rigault 2004-11-10 10:27:06 EST
After I gave more thought to this, I am now convinced that it is a 
bug in Qt, and *not* in the kernel. 
Currently, Qt does not follow the lib(32bit)/lib64(64bit) philosophy: 
On 64bit, it has 
and libs are in $(QTDIR)/lib 
Qt should be packaged consistently with other libraries, and 
therefore should have: 
$(QTDIR)/lib <- 32bit 
$(QTDIR)/lib64 <- 64bit 
$(QTDIR)/bin <- executables (64bit on x86_64) 
This is exactly what is done for X11R6 for example. 
I am currently working on adapting the default KDE building script 
(konstruct) to reflect the consistent 32/64bit for x86_64 division 
across all KDE. There will be 
$(QTDIR)/lib <- 32bit 
$(QTDIR)/lib64 <- 64bit 
$(KDEDIR)/lib <- 32bit 
$(KDEDIR)/lib64 <- 64bit 
and so on. 
Comment 5 Dave Jones 2005-07-15 14:25:19 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 6 Ngo Than 2005-09-29 07:08:57 EDT
I don't think it's a bug in in qt. The Makefile in kconfig should use  
the QTLIB enviroment to check the qt library on the system (KDE stuff uses  
this QTLIB enviroment for checking qt lib).  
I have done a patch, which should resolve this problem. Dave, it would be nice 
if the fix could be included in kernel upstream.  
--- linux-2.6.13/scripts/kconfig/Makefile.orig  2005-09-29 13:02:31.000000000  
+++ linux-2.6.13/scripts/kconfig/Makefile       2005-09-29 13:01:05.000000000  
@@ -108,7 +108,7 @@  
 HOSTCFLAGS_lex.zconf.o := -I$(src)  
 HOSTCFLAGS_zconf.tab.o := -I$(src)  
-HOSTLOADLIBES_qconf    = -L$(QTLIBPATH) -Wl,-rpath,$(QTLIBPATH) -l$(QTLIB)  
+HOSTLOADLIBES_qconf    = -L$(QTLIBPATH) -Wl,-rpath,$(QTLIBPATH) -l$(LIBS_QT)  
 HOSTCXXFLAGS_qconf.o   = -I$(QTDIR)/include -D LKC_DIRECT_LINK  
 HOSTLOADLIBES_gconf    = `pkg-config gtk+-2.0 gmodule-2.0 libglade-2.0  
@@ -142,11 +142,16 @@  
          false; \  
        fi; \  
        LIBPATH=$$DIR/lib; LIB=qt; \  
-       $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \  
-         LIBPATH=$$DIR/lib/$$($(HOSTCXX) -print-multi-os-directory); \  
-       if [ -f $$LIBPATH/libqt-mt.so ]; then LIB=qt-mt; fi; \  
-       echo "QTDIR=$$DIR" > $@; echo "QTLIBPATH=$$LIBPATH" >> $@; \  
-       echo "QTLIB=$$LIB" >> $@; \  
+       if [ -f $$QTLIB/libqt-mt.so ] ; then \  
+               LIB=qt-mt; \  
+               LIBPATH=$$QTLIB; \  
+       else \  
+               $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \  
+                       LIBPATH=$$DIR/lib/$$($(HOSTCXX)  
-print-multi-os-directory); \  
+               if [ -f $$LIBPATH/libqt-mt.so ]; then LIB=qt-mt; fi; \  
+       fi; \  
+       echo "QTDIR=$$DIR" > $@; echo "QTLIBPATH=$$LIBPATH" >> $@; \  
+       echo "LIBS_QT=$$LIB" >> $@; \  
        if [ ! -x $$DIR/bin/moc -a -x /usr/bin/moc ]; then \  
          echo "*"; \  
          echo "* Unable to find $$DIR/bin/moc, using /usr/bin/moc instead.";  
Comment 7 Dave Jones 2005-11-04 16:27:16 EST
*** Bug 172303 has been marked as a duplicate of this bug. ***
Comment 8 Dave Jones 2005-11-04 16:28:09 EST
Pointer to patch sent upstream. Should go in soon hopefully.

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