Re: old_procfs.h and large file environment

From: Roger Faulkner (roger.faulkner_at_sun.com)
Date: 11/29/04 

Date: 28 Nov 2004 22:19:32 -0800

Shea Martin <smartin@arcis.com> wrote in message news:<30paikF33jrd9U1@uni-berlin.de>...
> We are trying to demo Sun's new compilers. We compile our code 32-bit.
> We have a program which requires large file support, and <sys/procfs.h>.
>
> The compile flag (for now) is -D_FILE_OFFSET_BITS=64. This compiles
> fine with the old Sun Workshop 5.0 compilers, but the Studio 9 compilers
> give this message:
> "/usr/include/sys/old_procfs.h", line 39: Error: #error "Cannot use
> procfs in the large file compilation environment".
> *** Error code 1
>
> How can I fix this? I found people who had this similar error message in
> google, but no solution (though I suspect it is a simple on).

As Casper Dix pointed out, the only way to fix this is not
to attempt it. Everything else in this mail thread appears
to be a distraction from the main point.

The /proc data structures defined in <sys/procfs.h> and
<sys/old_procfs.h> contain types, such as 'off_t' which
are redefined by the large file compilation environment
(32 bit types vs 64 bit types).

Therefore a 32-bit application that is compiled using the
large file compilation environment and that also uses the
/proc interfaces would malfunction if the header files
didn't prevent them from being compiled that way.

There are several things you can/should do:

1. Put the code that uses the /proc interfaces in
   separate source files and compile them without
   using the large file compilation environment.
   Be careful not to pass objects like 'struct stat'
   between functions compiled with and without the
   large file compilation environment (just be careful).
   
2. Use the new structured /proc interfaces rather than
   the old ioctl-based interfaces (include <procfs.h>
   rather than <sys/procfs.h> and change your ioctl()s
   into lseek())/read()/write() or better, pread()/pwrite()).
   
3. Since a 32-bit process cannot examine or control a
   64-bit process but a 64-bit process can examine/control
   a 32-bit process, make your /proc application be 64-bit-safe
   and compile it as a 64-bit application on machines that
   support 64-bit applications (like opteron for Solaris 10
   or sparc since Solaris 7) and compile it as a non-large-file
   32-bit application for machines that support only 32-bit
   applications (like x86 machines).
   
Roger Faulkner
roger.faulkner@sun.com