make xconfig broken in bk current
Quoted 14 lines · Roman Zippel
Hi,
Quoted 9 lines · Ed Tomlinson
make -f
scripts/Makefile.buildobj=scripts/kconfigscripts/kconfig/qconf
g++ -oscripts/kconfig/qconfscripts/kconfig/kconfig_load.oscripts/kconfig/qconf.o-L/usr/share
/qt/lib -Wl,-rpath,/usr/share/qt/lib -lqt-mt -ldl scripts/kconfig/qconf.o(.text+0x31): In function `ConfigView::tr(char const*, char const*)':
: undefined reference to `QApplication::translate(char const*, char : const*, char const*, QApplication:
:Encoding) const'
Quoted 3 lines
Which distribution do you use?
It looks like you try to use a different g++ version than qt was compiled with.
This makes sense. Debian has changed its default compiler to 3.2 in sid... Suspect we will get quite a few reports like this one.
Solution would seem to be to fix the links in /usr/bin for:
gcc
g++
gcov
cpp
to point at the 2.95 binary, make clean xconfig
Thanks
Ed Tomlinson
PS. The kernel will not link here using 3.2....
Quoted 6 lines · Ed Tomlinson
Quoted 3 lines
Which distribution do you use?
It looks like you try to use a different g++ version than qt was compiled with.This makes sense. Debian has changed its default compiler to 3.2 in sid... Suspect we will get quite a few reports like this one.
Can I just repeat my request to move this Qt stuff entirely out of the kernel package, where it belongs ?
The current detection doesn't even start to get things working correctly.
regards
john
Signature · 2 lines
Khendon's Law: If the same point is made twice by the same person, the thread is over.
Quoted 2 lines · John Levon
Can I just repeat my request to move this Qt stuff entirely out of the kernel package, where it belongs ?
I would like to see it stay within the kernel for the following reasons:
1) It works as it is for those who have QT
2) It's more appealing to some people with a grapical frontend
3) If it fails, people can revert back to menuconfig
4) It does not take up much space. ~2 files
The problem seems that some people does not like the QT choice. But only one attemp has been made (that I know of) implementing an alternative graphical frontend. (Romain Lievin - GTK)
I you do not like the QT version - don't use it.
If too many people post error - get it fixed.
Simple...
Sam
Quoted 6 lines · Sam Ravnborg
I would like to see it stay within the kernel for the following reasons:
1) It works as it is for those who have QT
2) It's more appealing to some people with a grapical frontend
3) If it fails, people can revert back to menuconfig
4) It does not take up much space. ~2 files
Quoted 7 lines
The problem seems that some people does not like the QT choice. But only one attemp has been made (that I know of) implementing an alternative graphical frontend. (Romain Lievin - GTK)
I you do not like the QT version - don't use it.
If too many people post error - get it fixed.
Simple...
I do not want it removed because it's a graphical frontend, or because it's using Qt. I want it removed because it is an inappropriate package to have it in.
All else being equal, code should not be in the kernel package. Please explain the *advantages* of including it in the same package.
moc binary detection is broken, btw if the qt dir guessing is used (a bad idea in the first place). That's just an obvious one, there are undoubtedly other problems.
Sorry but it's just bizarre having patches for some GUI going through lkml
regards
john
Signature · 2 lines
Khendon's Law: If the same point is made twice by the same person, the thread is over.
Hi,
Quoted 2 lines · John Levon
Can I just repeat my request to move this Qt stuff entirely out of the kernel package, where it belongs ?
We can discuss this during 2.7, until then I prefer to keep it close to the kernel, as the config system still has to mature a bit more.
Quoted 2 lines
The current detection doesn't even start to get things working correctly.
For example?
bye, Roman
Quoted 5 lines · Roman Zippel
Quoted 2 lines
Can I just repeat my request to move this Qt stuff entirely out of the kernel package, where it belongs ?
We can discuss this during 2.7, until then I prefer to keep it close to the kernel, as the config system still has to mature a bit more.
OK, so you're fine with the moving to a different package when the config library reaches a stable API ? Fair enough.
Quoted 4 lines
Quoted 2 lines
The current detection doesn't even start to get things working correctly.
For example?
You don't seem to set MOC correctly if you guess a Qt dir. It doesn't cater for binaries called moc2 or libraries called qt3 or qt2[1]
regards
john
[1] I can't remember if some of these are only present on FreeBSD in which case it wouldn't be relevant
Signature · 2 lines
Khendon's Law: If the same point is made twice by the same person, the thread is over.
Hi,
Quoted 5 lines · John Levon
Quoted 2 lines
We can discuss this during 2.7, until then I prefer to keep it close to the kernel, as the config system still has to mature a bit more.
OK, so you're fine with the moving to a different package when the config library reaches a stable API ? Fair enough.
Yes, my main requirement is that the separate package is working fine in a few distributions.
Quoted 2 lines
You don't seem to set MOC correctly if you guess a Qt dir. It doesn't cater for binaries called moc2 or libraries called qt3 or qt2[1]
I haven't seen this yet and I would expect (sym)links to the default version.
bye, Roman
Hi,
Quoted 4 lines
This makes sense. Debian has changed its default compiler to 3.2 in sid... Suspect we will get quite a few reports like this one.
Solution would seem to be to fix the links in
/usr/binfor:
Until qt is recompiled, "make HOSTCXX=g++-2.95 xconfig" should do it.
bye, Roman