Bug 137926
| Summary: | Cannot make xconfig on x86_64 because of qt (solution) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Philippe Rigault <prigault> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | umar, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-12-01 06:41:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Philippe Rigault
2004-11-02 21:32:28 UTC
it's a bug in kernel, reassign it to correct component. i remember that i already sent a fix to Arjan while ago. 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 kernel.org). 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. the ideal situation is for this to get fixed in the mainline kernel, and have that propagate back into Fedora naturally. 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 QTDIR=/usr/lib64/qt and libs are in $(QTDIR)/lib Qt should be packaged consistently with other libraries, and therefore should have: QTDIR=/usr/qt-3.3 $(QTDIR)/lib <- 32bit $(QTDIR)/lib64 <- 64bit $(QTDIR)/bin <- executables (64bit on x86_64) etc. 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. 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. 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
+0200
+++ linux-2.6.13/scripts/kconfig/Makefile 2005-09-29 13:01:05.000000000
+0200
@@ -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)
-ldl
+HOSTLOADLIBES_qconf = -L$(QTLIBPATH) -Wl,-rpath,$(QTLIBPATH) -l$(LIBS_QT)
-ldl
HOSTCXXFLAGS_qconf.o = -I$(QTDIR)/include -D LKC_DIRECT_LINK
HOSTLOADLIBES_gconf = `pkg-config gtk+-2.0 gmodule-2.0 libglade-2.0
--libs`
@@ -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.";
\
*** Bug 172303 has been marked as a duplicate of this bug. *** Pointer to patch sent upstream. Should go in soon hopefully. |