I get
make -f scripts/Makefile.build obj=scripts
make -f scripts/Makefile.build obj=scripts/kconfig scripts/kconfig/qconf
g++ -o scripts/kconfig/qconf scripts/kconfig/kconfig_load.o scripts/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'
..
..
along with many more error doing:
make xconfig
in bk current.
Ideas
Ed Tomlison
Hi,
Ed Tomlinson wrote:
> make -f scripts/Makefile.build obj=scripts/kconfig scripts/kconfig/qconf
> g++ -o scripts/kconfig/qconf scripts/kconfig/kconfig_load.o scripts/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'
Which distribution do you use?
It looks like you try to use a different g++ version than qt was
compiled with.
bye, Roman
Roman Zippel wrote:
> Hi,
>
> Ed Tomlinson wrote:
>
>> make -f scripts/Makefile.build obj=scripts/kconfig scripts/kconfig/qconf
>> g++ -o scripts/kconfig/qconf scripts/kconfig/kconfig_load.o
>> scripts/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'
>
> 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....
On Sun, Jan 12, 2003 at 03:12:59PM -0500, Ed Tomlinson wrote:
> > 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
--
Khendon's Law: If the same point is made twice by the same person,
the thread is over.
On Sun, Jan 12, 2003 at 08:31:50PM +0000, John Levon wrote:
> 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
On Sun, Jan 12, 2003 at 10:03:49PM +0100, Sam Ravnborg wrote:
> 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...
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
--
Khendon's Law: If the same point is made twice by the same person,
the thread is over.
Hi,
John Levon wrote:
> 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.
> The current detection doesn't even start to get things working
> correctly.
For example?
bye, Roman
Hi,
> 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:
Until qt is recompiled, "make HOSTCXX=g++-2.95 xconfig" should do it.
bye, Roman
On Mon, Jan 13, 2003 at 12:56:54AM +0100, Roman Zippel wrote:
> > 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.
> > 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
--
Khendon's Law: If the same point is made twice by the same person,
the thread is over.
Hi,
John Levon wrote:
> > 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.
> 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