Will try and fix on my own and see what I come up with.

build02-sol8-x86 :: ~/src/kde3.3rc2/kdebase-3.3.0/kcontrol/info > head -47 /usr/include/sys/swap.h | tail -2
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error  "Cannot use swapctl in the large files compilation environment"


Here is a questionable patch that works:

--- /home/clayne/src/kde/kdebase/kcontrol/info/memory_solaris.cpp       Tue Feb 24 03:30:07 2004
+++ /home/clayne/src/kde3.3rc2/kdebase-3.3.0/kcontrol/info/memory_solaris.cpp   Sat Aug 14 07:22:53 2004
@@ -7,9 +7,15 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <kstat.h>
 #include <sys/stat.h>
-#include <sys/swap.h>
+
+#ifdef _FILE_OFFSET_BITS
+#  undef _FILE_OFFSET_BITS
+#  include <sys/swap.h>
+#else
+#  include <sys/swap.h>
+#endif
 
 #define PAGETOK(a) (( (t_memsize) sysconf( _SC_PAGESIZE )) *  (t_memsize) a)
 
 void KMemoryWidget::update() {

I don't think this is going to work, however, even if it compiles alright after making those changes.

As found on USENET:

From: Dave Thompson (thompd@guppi.net)
Subject: swapctl() equivalent with _FILE_OFFSET_BITS=64? 

This is the only article in this thread 	
View: Original Format	
Newsgroups: comp.unix.solaris
Date: 2001-10-23 12:07:19 PST 
	

I notice that I cannot use swapctl() in a C program if _FILE_OFFSET_BITS is set
to 64 (actually, I cannot even #include<swap.h>).  Is there a way to get swap
information from a C program that will give me the same information as
swapctl() when _FILE_OFFSET_BITS is 64, or am I SOL?  Unfortunately, I also am
getting some filesystem information that does not come out correctly
otherwise...

Thanks in advance!

Dave Thompson
dave@guppi.net

Alright, I'm thinking that _FILE_OFFSET_BITS=64 has to be undef'd altogether.

Just got another:

if /bin/ksh ../../../libtool --silent --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include   -DOS_Solaris -I./../../fonts -I/usr/local/kde/include -I/usr/local/include -I/usr/local/X11R6/include  -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT  -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_SOLARIS -DSVR4 -D_FILE_OFFSET_BITS=64  -O2   -D_GNU_SOURCE -MT GetPid.lo -MD -MP -MF ".deps/GetPid.Tpo" -c -o GetPid.lo GetPid.c; \
then mv -f ".deps/GetPid.Tpo" ".deps/GetPid.Plo"; else rm -f ".deps/GetPid.Tpo"; exit 1; fi
In file included from /usr/include/procfs.h:26,
                 from GetPid.c:246:
/usr/include/sys/procfs.h:44:2: #error "Cannot use procfs in the large file compilation environment"

Ended up doing something similar for GetPid.c, i.e.:

#ifdef _FILE_OFFSET_BITS
#undef _FILE_OFFSET_BITS
#endif

Build continuing.

ksysguardd as well:

make[4]: Entering directory `/home/clayne/src/kde3.3rc2/kdebase-3.3.0/ksysguard/ksysguardd/Solaris'
if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I./../../CContLib -I./..  -DQT_THREAD_SUPPORT  -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_SOLARIS -DSVR4 -D_FILE_OFFSET_BITS=64  -O2   -D_GNU_SOURCE -MT Memory.o -MD -MP -MF ".deps/Memory.Tpo" -c -o Memory.o Memory.c; \
then mv -f ".deps/Memory.Tpo" ".deps/Memory.Po"; else rm -f ".deps/Memory.Tpo"; exit 1; fi
In file included from Memory.c:27:
/usr/include/sys/swap.h:47:2: #error "Cannot use swapctl in the large files compilation environment"
make[4]: *** [Memory.o] Error 1
make[4]: Leaving directory `/home/clayne/src/kde3.3rc2/kdebase-3.3.0/ksysguard/ksysguardd/Solaris'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/clayne/src/kde3.3rc2/kdebase-3.3.0/ksysguard/ksysguardd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/clayne/src/kde3.3rc2/kdebase-3.3.0/ksysguard'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/clayne/src/kde3.3rc2/kdebase-3.3.0'
make: *** [all] Error 2

BTW:

The FILE_OFFSET is being inherited from the Qt.

I've since built Qt 3.3.3 (just released) w/ -no-largefile and am rebuilding kdelibs/kdebase now.

As mentioned in another bug. I'll be trying to fix the autoconf/automake for this issue.

I just finished compiling my fix for this,
(Solaris 2.8).
I compiled QT with -no-largefile and kdebase
with --disable-largefile.  After this though
each makefile did not properly define 
D_FILE_OFFSET_BITS, so I created a small perl
script to fix it
#!/usr/bin/perl
@tries=`find . -name Makefile -print`;
foreach(@tries) {
   chop($_);
   system("cp $_ $_.orig");
   system("sed 's/BITS=/BITS=32/' $_ > $_.1");
   system("cp $_.1 $_");
}
This fixed all my compile problems and is a good temporary
fix if you need it.

I'm sorry, but turning off large file support isn't an option for me and is a poor workaround.

Here's my workaround (OK, a kludge but it's relatively clean and doesn't affect the rest of the system):-

--- memory_solaris.cpp.orig     Thu Nov 11 09:24:27 2004
+++ memory_solaris.cpp  Thu Nov 11 09:39:48 2004
@@ -4,6 +4,14 @@
  *  Torsten Kasch <tk@Genetik.Uni-Bielefeld.DE>
  */
 
+#ifdef _LARGEFILE64_SOURCE
+#undef _LARGEFILE64_SOURCE
+#endif
+
+#ifdef _FILE_OFFSET_BITS
+#undef _FILE_OFFSET_BITS
+#endif
+
 #include <unistd.h>
 #include <stdlib.h>
 #include <kstat.h>

This was resolved a long time ago.

Check CVS rlog on that file.

It's still in the 3.3.1 release version, or at least the problem is.

Fixed in KDE 3.4.3 packages; not relevant in KDE4 which handles largefile stuff slightly differently.