KExtendedSocket on 64bit systems

Ian Reinhart Geiser geiseri at
Tue Sep 17 13:06:43 BST 2002

Hash: SHA1

On Monday 16 September 2002 10:03 pm, Waldo Bastian wrote:
> On Monday 16 September 2002 06:33 pm, Ian Reinhart Geiser wrote:
> > Greetings
> > 	As I have been mucking with solaris and building KDE, I ran into a
> > problem building kdenetwork.
> > /usr/local/src/kdenetwork/kdict/dict.cpp: In method `void
> > DictAsyncClient::openConnection()':
> > /usr/local/src/kdenetwork/kdict/dict.cpp:788: cannot declare variable
> > `ks' to be of type `KExtendedSocket'
> > /usr/local/src/kdenetwork/kdict/dict.cpp:788:   since the following
> > virtual functions are abstract:
> > /qt3/include/qiodevice.h:128:   bool QIODevice::open64(int)
> >
> > Am I wrong to assume that KExtendedSocket needs to have an open64(int)?
> Yes, you are wrong.
> > If so what does it need to have inside of it?
> It's probably because one of the system headers does a
> #define open open64

Actually this is part of a bigger problem.  For some reason truncate (part of 
QString) and open (part of kextsocket) are used all over the place.  But if 
someone includes a system header like unistd.h or fnctl.h then we are screwed 
because all open() and truncate() are turned to open64(int) and 
truncate64(int&).  After chaseing tons of stuff in kdenetwork and pim, im 
wondering if there is a safe way to fix this in kdelibs.  If anyone includes 
kdebug.h in their code after kprocess.h, then their code will not build on 
64bit platforms.

Any ideas here?  Or should I keep plugging away module by module fixing this 
issue by #undefines and moveing include orders arround.

- -ian reinhart geiser

- -- 
"I think it is true for all _n. I was just playing it safe with _n >= 3
because I couldn't remember the proof."
		-- Baker, Pure Math 351a
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list