Hello,
I found that tqt.h is modified only at install stage. If I define USE_QT3
before compilation, the compilation stop with this error:
tqinputcontext.h:32:27: error: qinputcontext.h: No such file or directory
This is intended behaviour? If yes, for what purpose is designed in this way?
--
Serghei
I'm attaching a new log for building kdebase.
I can build arts and kdelibs.
I think I discovered why the builds on the virtual machine were so much slower. I was using a single processor kernel rather than smp. I'll fix that and hopefully that eliminates that particular problem.
I have yet to figure out why nothing compiles in the chroot environment.
Darrell
Attached is a log of the failed kdebase build.
The follwing message appears several times:
TEPty.h:43: error: invalid use of incomplete type 'struct KPty'
Another message:
/usr/include/kprocess.h:34: error: forward declaration of 'struct KPty'
I checked /usr/include and kprocess.h is installed from my previous kdelibs svn package.
Darrell
I'm stumped. The problem is with my chroot environment.
I spent the past few hours whittling away at both the chroot environment and the virtual machine trying to find the difference. Currently, as far as package installations go, the two machines are identical.
Granted, although sandboxed, the chroot is not perfectly isolated like the virtual machine. Something is confusing the build process in the chroot environment that the virtual machine can't see. A chroot environment is not supposed to be able to see above/outside its internal root level. Thus I don't know what the chroot environment sees that the virtual machine can't.
I can build in the virtual machine but as I mentioned previously, the build process is slower than on physical hardware. I wanted the chroot environment so I could use the physical hardware and build faster.
I'll see how far I get rebuilding arts and kdelibs in the virtual machine. Then I'll try kdebase with your changes from a couple of days ago. I'll keep troubleshooting with the chroot environment too.
With that said, I am attaching a new log of the failed arts build in the chroot environment. Perhaps something there might provide you a clue where I can troubleshoot or what might cause arts to fail in one environment but not the other.
Oops. I forgot to attach the log!
I am attaching a log of the kdebase build attempt.
In addition to the failure, please look at the following configure messages:
==================================================
acinclude.m4:6591: warning: underquoted definition of _LT_AC_TRY_LINK
==================================================
unknown icon type in kate/pics/Makefile.in (sessionchooser.png)
==================================================
checking linux/cdrom.h usability... no
checking linux/cdrom.h presence... yes
configure: WARNING: linux/cdrom.h: present but cannot be compiled
configure: WARNING: linux/cdrom.h: check for missing prerequisite headers?
configure: WARNING: linux/cdrom.h: see the Autoconf documentation
configure: WARNING: linux/cdrom.h: section "Present But Cannot Be Compiled"
configure: WARNING: linux/cdrom.h: proceeding with the preprocessor's result
configure: WARNING: linux/cdrom.h: in the future, the compiler will take precedence
checking for linux/cdrom.h... yes
==================================================
A header file exists at /usr/include/linux/cdrom.h
--- On Mon, 8/30/10, Serghei Amelian <serghei(a)thel.ro> wrote:
> From: Serghei Amelian <serghei(a)thel.ro>
> Subject: Re: [trinity-devel] tqtinterface compilation problem
> To: trinity-devel(a)lists.pearsoncomputing.net
> Date: Monday, August 30, 2010, 6:12 PM
> Actually --enable-qt4 is not recognized by configure script
> at all. I tried
> with plain "./configure", without parameters.
>
> > If you are compiling for Qt3, then something might be
> amiss in your build
> > setup. Please make sure you have all Qt
> development headers installed,
> > and if you don't mind posting the full output of the
> commands you listed
> > above I may be able to shed more light on the
> problem.
>
> I using gentoo and I have already KDE-3 installed, so my
> QT-3 setup is fine, I
> think.
>
> I attached folowing files:
>
> log1.txt is output of "make -f admin/Makefile.common"
> log2.txt is output of "./configure"
> log3.txt is output of "make"
>
> Also, I attached config.log
>
> I'm not sure what meaning the message "You are attempting
> to compile Trinity
> without the Trinity Qt Interface installed. Please
> install
> libtqtinterface-dev and try again!"
I discovered the hard way that trying to build the Trinity packages with KDE 3.5.10 installed will cause many headaches.
I created a virtual machine without KDE installed and I built tqtinterface there. You still need qt3 installed.
Also, you need to rebuild the make files with each package. Much is changed with Trinity include files and these make files need to be rebuilt.
On my system I run the following commands in my build scripts:
cp -Rp /usr/lib/build/libtool.m4 admin/libtool.m4.in
cp -Rp /usr/lib/build/ltmain.sh admin/ltmain.sh
make -f admin/Makefile.common
Locations might be different for Gentoo.
I'm attaching the build script I used to create a tqtinterface package for Slackware. Hopefully that provides some ideas of what you need in Gentoo.
I hope that helps.
Darrell
The kdebase build failed within a few minutes. I'm attaching a log.
Nothing compiled. Only the end message that configure was done and that's all.
arts and kdelibs from svn are installed.
I would think that if kdelibs did not compile correctly I would see some kind of error message, but I see nothing. I am not using any -j flags with the make command. I'm inclined to think something is awry with the makefiles, but I'm guessing.
The odd thing is after configure completes the next command in the build script is:
make || exit 1
Yet the build script tries to continue as though make exited without errors.
Here is the affected portion of the build script:
==================================================
CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
--prefix=${PREFIX} \
--sysconfdir=${SYSCONFDIR} \
--libdir=${LIBDIR} \
--with-ssl-dir=${PREFIX} \
--with-shadow \
--disable-debug \
--disable-dnssd \
--program-prefix="" \
--program-suffix="" \
--build=$TARGET-slackware-linux
make || exit 1
==================================================
Weird. Quite weird!
Some messages I noticed:
==================================================
acinclude.m4:6591: warning: underquoted definition of _LT_AC_TRY_LINK
==================================================
unknown icon type in kate/pics/Makefile.in (sessionchooser.png)
==================================================
checking linux/cdrom.h usability... no
checking linux/cdrom.h presence... yes
configure: WARNING: linux/cdrom.h: present but cannot be compiled
configure: WARNING: linux/cdrom.h: check for missing prerequisite headers?
configure: WARNING: linux/cdrom.h: see the Autoconf documentation
configure: WARNING: linux/cdrom.h: section "Present But Cannot Be Compiled"
configure: WARNING: linux/cdrom.h: proceeding with the preprocessor's result
configure: WARNING: linux/cdrom.h: in the future, the compiler will take precedence
checking for linux/cdrom.h... yes
==================================================
A header file exists at /usr/include/linux/cdrom.h
I am using 2.6.27.48 but I leave the original 2.6.27.7 headers installed because that is what the Slackware 12.2 release was compiled against. I never have had a problem before with kernel headers.
Darrell
> That was part of it! ;-)
>
> Is the previously mentioned error still occurring in the
> virtual machine build? It may have originally arisen
> due to the old KDE3.5.10 header files, and krb5 may be
> a red herring. I will wait for the build log from
> the virtual machine before passing judgment.
The error occurred again in my new environment. The build did not fail until about an hour later, at the lgssapi_krb5 test. I don't know how close that is to the end of the build, but I suspect pretty close. That much is good news!
Like the avahi test, I thought I had better test the build process with krb5 installed and not installed. I built the krb5 (kerberos) package and installed in my build environment.
I ran the build of kdelibs with krb5 installed.
Same result, failing at the lgssapi_krb5 test.
I'm attaching another log of the build output.
I'm attaching a copy of the krb5 package contents.
Of course, krb5/kerberos should not be a build requirement, only an option.
When building kdelibs in my new build environment I notice the following messages when building. I don't know whether the messages are harmless or meaningful.
configure: WARNING: Could not find krb5-config
(Note: the file exists at /usr/kerberos/bin/krb5-config)
wrong input (flag != 4) at admin/conf.change.pl line 117, <> line 1997.
config.status: WARNING: 'kdecore/kde-config.cpp.in' seems to ignore the --datarootdir setting
(I do not have that option set in my build script.)
(repeats several times with different line numbers)
ltdl.c: In function 'sys_dl_open':
ltdl.c:605: warning: unused parameter 'loader_data'
(this error was in the arts build too)
ksock.cpp: In member function 'long unsigned int KSocket::ipv4_addr()':
ksock.cpp:214: warning: 'peerAddress' is deprecated (declared at kextsock.h:1001)
ksock.cpp: In static member function 'static bool KSocket::initSockaddr(ksockaddr_in*, const char*, short unsigned int, int)':
ksock.cpp:244: warning: 'lookup' is deprecated (declared at kextsock.h:984)
ksock.cpp:253: warning: 'address' is deprecated (declared at kextsock.h:1078)
ksock.cpp: In member function 'virtual void KServerSocket::slotAccept(int)':
ksock.cpp:420: warning: '__comp_ctor ' is deprecated (declared at ksock.cpp:105)
kextsock.cpp: In member function 'bool KExtendedSocket::setAddressReusable(bool)':
kextsock.cpp:513: warning: 'setAddressReusable' is deprecated (declared at kextsock.h:1020)
kextsock.cpp: In member function 'const KSocketAddress* KExtendedSocket::localAddress()':
kextsock.cpp:728: warning: 'localAddress' is deprecated (declared at kextsock.h:992)
kextsock.cpp: In member function 'const KSocketAddress* KExtendedSocket::peerAddress()':
kextsock.cpp:743: warning: 'peerAddress' is deprecated (declared at kextsock.h:1001)
kextsock.cpp: In member function 'virtual int KExtendedSocket::listen(int)':
kextsock.cpp:869: warning: 'setAddressReusable' is deprecated (declared at kextsock.cpp:521)
kextsock.cpp: In member function 'virtual int KExtendedSocket::connect()':
kextsock.cpp:1051: warning: 'setAddressReusable' is deprecated (declared at kextsock.cpp:521)
kextsock.cpp:1073: warning: 'setAddressReusable' is deprecated (declared at kextsock.cpp:521)
kextsock.cpp: In member function 'void KExtendedSocket::connectionEvent()':
kextsock.cpp:1876: warning: 'setAddressReusable' is deprecated (declared at kextsock.cpp:521)
kextsock.cpp:1900: warning: 'setAddressReusable' is deprecated (declared at kextsock.cpp:521)
kextsock.cpp: In static member function 'static int KExtendedSocket::resolve(KSocketAddress*, QString&, QString&, int)':
kextsock.cpp:2008: warning: 'resolve' is deprecated (declared at kextsock.cpp:1989)
kpassdlg.cpp: In static member function 'static int KPasswordDialog::getPassword(QCString&, QString, int*)':
kpassdlg.cpp:559: warning: '__comp_ctor ' is deprecated (declared at kpassdlg.cpp:325)
kpassdlg.cpp: In static member function 'static int KPasswordDialog::getNewPassword(QCString&, QString)':
kpassdlg.cpp:574: warning: '__comp_ctor ' is deprecated (declared at kpassdlg.cpp:325)
kfilemetainfo.cpp: In static member function 'static KFileMetaInfoItem::Data* KFileMetaInfoItem::Data::makeNull()':
kfilemetainfo.cpp:91: warning: 'setObject' is deprecated (declared at ../../kdecore/kstaticdeleter.h:85)
kfilemetainfo.cpp: In static member function 'static KFileMetaInfo::Data* KFileMetaInfo::Data::makeNull()':
kfilemetainfo.cpp:774: warning: 'setObject' is deprecated (declared at ../../kdecore/kstaticdeleter.h:85)
kfilemetainfo.cpp: In destructor 'virtual KFileMetaInfoProvider::~KFileMetaInfoProvider()':
kfilemetainfo.cpp:927: warning: 'setObject' is deprecated (declared at ../../kdecore/kstaticdeleter.h:85)
kfilemetainfo.cpp: In static member function 'static KFileMetaInfoGroup::Data* KFileMetaInfoGroup::Data::makeNull()':
kfilemetainfo.cpp:1464: warning: 'setObject' is deprecated (declared at ../../kdecore/kstaticdeleter.h:85)
(repeats several times)
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libSM.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libICE.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libtqt.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libX11.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libXext.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved
(the files exists at /usr/lib/libstdc++.la so I don't know what is checking in that directory.)
I hope this helps!
> >> #include <tqevent.h>
> >>
> >> directly before this block of text:
> >>
> >> #include <tqvaluelist.h>
> >> #include <tqwindowdefs.h>
> >> #include <kdelibs_export.h>
> >> #include <X11/Xlib.h>
> >>
> >> Retry the compilation; if it gets farther please
> let me
> >> know.
I added that change to kipc.cpp and kept the same change in kxerrorhandler.h.
I'm curious: why the same change but one in a cpp and the other in an h file. Why not both cpp or h files?
The package compiled for about 20 minutes. That is progress --- the previous failure occurred quickly at about two minutes.
I'm attaching the full build output.
I'm unsure but looks like there are gcc file location errors. I'm using GCC 4.2.4, which is what comes with Slackware 12.2.
Note: I realize the free/libre software world moves at a maddening pace. Some people might consider Slackware 12.2 ancient or obsolete, but actually is more recent than Debian Lenny. Lenny is still supported and will be for a long while yet. I presume the Trinity KDE packages are compatible with Lenny and therefore should be compatible with Slackware 12.2. Also, Lenny and 12.2 were the last distros to support KDE 3.5.10 and I think Trinity should be backwards compatible with those distros --- at least for a long while.
