old_procfs.h and large file environment
Shea Martin
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).
Thanks,
~S
Casper H.S. Dik
You can't; it's not supported.
It shouldn't compile with the old compilers either.
Casper
Rich Teer
> "/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).
New apps shouldn't be using the old (ioctl) procfs interfaces,
so they shouldn't be including <sys/old_procfs.h>.
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Nick Maclaren
Rich Teer <rich...@rite-group.com> wrote:
>On Fri, 26 Nov 2004, Shea Martin wrote:
>
>> "/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).
>
>New apps shouldn't be using the old (ioctl) procfs interfaces,
>so they shouldn't be including <sys/old_procfs.h>.
He said that it WASN'T a new application. He is clearly trying to
recompile an old one.
Unfortunately, Sun ONE Studio 9 has very poor source compatibility,
even with very clean, fully conforming codes, so there is going to
be ongoing trouble with it. We tried it, and have decided not to
'upgrade' to it, mainly for that reason.
The compatibility problems aren't just with Studio 8, but with most
other Unices, which is even more of a problem for us.
Regards,
Nick Maclaren.
Shea Martin
> On Fri, 26 Nov 2004, Shea Martin wrote:
>
>
>>"/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).
>
>
> New apps shouldn't be using the old (ioctl) procfs interfaces,
> so they shouldn't be including <sys/old_procfs.h>.
>
it definitely compiles with CC 5.0, but not with 5.6.
~S
Shea Martin
>
> It shouldn't compile with the old compilers either.
>
> Casper
Rich Teer
> He said that it WASN'T a new application. He is clearly trying to
> recompile an old one.
Right, must've missed that; apols to the OP.
> Unfortunately, Sun ONE Studio 9 has very poor source compatibility,
> even with very clean, fully conforming codes, so there is going to
Hrm, interesting. I'll have to give it a try...
Shea Martin
> On Fri, 26 Nov 2004, Shea Martin wrote:
>
>
>>"/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).
>
>
> New apps shouldn't be using the old (ioctl) procfs interfaces,
> so they shouldn't be including <sys/old_procfs.h>.
>
if _STRUCTURED_PROC and _KERNEL are both undefined. So the old compiler
must be defining one of these, but I can't tell which one.
~S
Shea Martin
the old compiler wasn't defining them either. So <sys/old_procfs.h> was
being included in the with the old compilers too. The old makefile I
had had a -w in the CCFLAGS so that the warning was not visible.
In the file /usr/include/sys/old_procfs.h there is a pre-processor check
to see if _FILE_OFFSET_BITS=64 is being used without _LP64 then issuing
#error "Cannot use procfs in the large file compilation environment".
So now there are 2 questions.
1.Why was this just a warning with the 5.0 compilers and a hard error in
the new ones?
2.What is the replacement for procfs when Large file support is needed?
THanks,
~Shea M.
Rich Teer
> more info:
> the old compiler wasn't defining them either. So <sys/old_procfs.h> was
> being included in the with the old compilers too. The old makefile I
> had had a -w in the CCFLAGS so that the warning was not visible.
Ah, that explains it. Personally, I turn on as many warning as possible.
> So now there are 2 questions.
> 1.Why was this just a warning with the 5.0 compilers and a hard error in
> the new ones?
No idea.
> 2.What is the replacement for procfs when Large file support is needed?
You need to use the new (since Solaris 2.6) method of accessing procfs.
Basically, rather than just opening /proc/PID and issuing an ioctl,
there are various files in a directory called /proc/PID, and you open
the one that contains the info you want. See the proc(4) man page for
more info--or better, Chapter 8 of my book (which happens to be the sample
chapter on the book's web site!).
HTH,
Nick Maclaren
Rich Teer <rich...@rite-group.com> wrote:
>On Fri, 26 Nov 2004, Shea Martin wrote:
>
>> more info:
>> the old compiler wasn't defining them either. So <sys/old_procfs.h> was
>> being included in the with the old compilers too. The old makefile I
>> had had a -w in the CCFLAGS so that the warning was not visible.
>
>Ah, that explains it. Personally, I turn on as many warning as possible.
I do, usually, but that wasn't feasible when writing that sort of
system code under Solaris until Solaris 8, because of the very slow
conversions of the system headers to C90. I can't remember which
they were, but a few headers wouldn't compile in full C90 mode until
Solaris 8, even though almost all had been cleaned up in Solaris 7.
>> So now there are 2 questions.
>> 1.Why was this just a warning with the 5.0 compilers and a hard error in
>> the new ones?
>
>No idea.
I have - this is the problem I referred to earlier :-(
Solaris 10 and Studio 9 are doing a rerun of the way that C90 and
POSIX support was introduced, back in the early days of Solaris.
And for almost identical reasons.
C90 and POSIX were syntactically and semantically incompatible with
the K&R C and Berkeley interfaces used under SunOS, for good reasons.
Sun bent over backwards to maintain compatibility with its old
interfaces, which is generally good, but was very slow to convert
the more systemish headers to compatible forms, which is bad. As
I said, this lasted until Solaris 7, which was long after you could
write system code in C90-only mode on most other systems.
For reasons that people on the national language bodies of SC22WG14
and followers of comp.std.c should be familiar with, C99 is both
syntactically and semantically incompatible with C90. It also
allows implementations to select between many language variants,
some of which are so incompatible that it is impossible to write
clean dual-mode code (as is generally possible with C90 and K&R).
Also, according to the rules, C99 has now replaced C90 as the official
standard for both ISO and ANSI.
POSIX 2001 (a.k.a. Unix 03 etc.) chose to go with the new official
C standard, which was an almost unavoidable decision, I suppose.
Sun have chosen to convert Solaris 10 to the new POSIX standard,
which was probably also unavoidable.
Sun have rejected the most imbecilically incompatible C99 option
(that of having built-in integer types longer than long), but did
choose the next most incompatible one (that of dropping support for
errno in <math.h> functions). That, however, is unlikely to be
relevant for most systemish codes. It is largely the syntactic
incompatibilities (e.g. some functions changing the type of their
arguments by adding restrict) that cause the trouble.
Unlike the previous (K&R/Berkeley to C90/POSIX) exercise, Sun have
chosen to do most of the migration in a single step, which should
at least avoid the previous problems. Unfortunately, this has been
done by providing C90/POSIX(1996) support only for legacy code, with
a very restrictive interpretation of legacy. As far as I can see,
this imposes the following restrictions:
1) The code must NOT be fully conformant with earlier POSIX (in
particular, it must not set _POSIX_SOURCE or _POSIX_C_SOURCE to any
value allowed in Solaris 9).
2) If compiled in C99 mode, it must not use any of the features of
C90 that are broken by C99 (e.g. it must not declare most library
functions explicitly, and so may not use their addresses as variables
or arguments).
3) If compiled in C90 mode, it must not use any facility except
those that were FULLY supported under Solaris 9 (which does not
include any new ones, or at least some of the half-supported systemish
ones).
4) Unlike with the K&R/C90 step, Studio 9 provides no compatibility
mode (no, -xc99 is NOT such a mode), and the approach taken in the
headers seems to be to select between K&R, C90 or C99.
To the best of my knowledge, Sun is the only major vendor that has
chosen to convert to C99 - every other one has taken a look at the
problems, consulted the few customers with Clue (who typically say
"No way, Jose"), and are moving cautiously.
Please note that not all problems are due to the above C-induced
shambles directly, but some are almost certainly caused by the need
to minimise the number of variant paths in the headers, and the
inevitable punning of attributes.
Regards,
Nick Maclaren.
Nick Maclaren
Sorry - a correction to my posting:
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>
> 1) The code must NOT be fully conformant with earlier POSIX (in
>particular, it must not set _POSIX_SOURCE or _POSIX_C_SOURCE to any
>value allowed in Solaris 9).
I missed out "If compiled in C99 mode, the default," from this.
Sorry.
Regards,
Nick Maclaren.
Casper H.S. Dik
>Unfortunately, Sun ONE Studio 9 has very poor source compatibility,
>even with very clean, fully conforming codes, so there is going to
>be ongoing trouble with it. We tried it, and have decided not to
>'upgrade' to it, mainly for that reason.
Is that a "c99" problem or another problem?
>The compatibility problems aren't just with Studio 8, but with most
>other Unices, which is even more of a problem for us.
Source shoudl be compatible, but the C99 standard made quite a few
incompatible changes to the C language; the compiler does allow you
to supress them.
But the error the OP had:
#error "Cannot use procfs in the large file compilation environment"
should have happened with the older compilers as well as the new
ones. That he didn't is puzzling unless he now compiles for 32 bit
and used to compile for 64 bit:
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error "Cannot use procfs in the large file compilation environment"
#endif
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Casper H.S. Dik
Exactly which options did you give; can you make a small self-contained
example which triggers this problem?
There's just no avoiding:
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error "Cannot use procfs in the large file compilation environment"
#endif
in 32 bit compilation mode.
Casper H.S. Dik
The error should occur in both cases; either in old_procfs or in
procfs, depending on whether _STRUCTURED_PROC is 0 or 1.
(If _STRUCTURED_PROC is not defined, it is defined as 0 in the top
of <sys/procfs.h>
Casper
Casper H.S. Dik
>> being included in the with the old compilers too. The old makefile I
>> had had a -w in the CCFLAGS so that the warning was not visible.
>Ah, that explains it. Personally, I turn on as many warning as possible.
Well, workshop 5 cc gives me:
cc -w -I.. m_sunos5.c -D_FILE_OFFSET_BITS=64 -c -DOSREV=510
"/usr/include/sys/procfs.h", line 44: #error: "Cannot use procfs in the large file compilation environment"
for a top source file (whether I use structured proc or not)
Nick Maclaren
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
>>Unfortunately, Sun ONE Studio 9 has very poor source compatibility,
>>even with very clean, fully conforming codes, so there is going to
>>be ongoing trouble with it. We tried it, and have decided not to
>>'upgrade' to it, mainly for that reason.
>
>Is that a "c99" problem or another problem?
I did try to explain :-(
Ab initio, C99, but compounded by POSIX and Sun's choice of C99
options.
>>The compatibility problems aren't just with Studio 8, but with most
>>other Unices, which is even more of a problem for us.
>
>Source shoudl be compatible, but the C99 standard made quite a few
>incompatible changes to the C language; the compiler does allow you
>to supress them.
I don't think that it would help to rephrase what I said. The problem
is that there is a solution to each INDIVIDUAL problem, but that real,
portable, conforming programs may hit enough problems that there is no
way to resolve all of them without rewriting.
In particular, the source is compatible only with a very restrictive
interpretation of what is acceptable - and that definitely does NOT
include programs that are portable between other Unices.
>But the error the OP had:
>
>#error "Cannot use procfs in the large file compilation environment"
>
>should have happened with the older compilers as well as the new
>ones. That he didn't is puzzling unless he now compiles for 32 bit
>and used to compile for 64 bit:
>
>#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
>#error "Cannot use procfs in the large file compilation environment"
>#endif
Yes, that is true, but look at the interactions between those symbols
and others in the environment. It is a minefield, there is no plan,
and you can get to only some objectives.
Regards,
Nick Maclaren.
shea martin
> On Fri, 26 Nov 2004, Shea Martin wrote:
>
>
>>more info:
>>the old compiler wasn't defining them either. So <sys/old_procfs.h> was
>>being included in the with the old compilers too. The old makefile I
>>had had a -w in the CCFLAGS so that the warning was not visible.
>
>
> Ah, that explains it. Personally, I turn on as many warning as possible.
>
>
>>So now there are 2 questions.
>>1.Why was this just a warning with the 5.0 compilers and a hard error in
>>the new ones?
>
>
> No idea.
>
>
>>2.What is the replacement for procfs when Large file support is needed?
>
>
> You need to use the new (since Solaris 2.6) method of accessing procfs.
> Basically, rather than just opening /proc/PID and issuing an ioctl,
> there are various files in a directory called /proc/PID, and you open
> the one that contains the info you want. See the proc(4) man page for
> more info--or better, Chapter 8 of my book (which happens to be the sample
> chapter on the book's web site!).
Ok, I will check this out. What is your website Rich? I remember going
there when your book first came out, but forget it now.
THanks,
~S
> HTH,
>
Rich Teer
> Ok, I will check this out. What is your website Rich? I remember going
> there when your book first came out, but forget it now.
It is: www.rite-group.com/rich (follow the book link).
Drazen Kacar
> 2) If compiled in C99 mode, it must not use any of the features of
> C90 that are broken by C99 (e.g. it must not declare most library
> functions explicitly, and so may not use their addresses as variables
> or arguments).
Section 7.1.4 says it's OK in general unless explicitly overriden in a
detailed function description. Could you provide a few examples of such
functions?
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
Drazen Kacar
> Casper H.S. Dik wrote:
> > You can't; it's not supported.
> <sys/procfs.h> is not supported? What is the replacement?
> >
> > It shouldn't compile with the old compilers either.
> It does.
Perhaps the old compiler has a private include directory and it's finding
modified include files there?
Nick Maclaren
Drazen Kacar <da...@fly.srk.fer.hr> wrote:
>Nick Maclaren wrote:
>
>> 2) If compiled in C99 mode, it must not use any of the features of
>> C90 that are broken by C99 (e.g. it must not declare most library
>> functions explicitly, and so may not use their addresses as variables
>> or arguments).
>
>Section 7.1.4 says it's OK in general unless explicitly overriden in a
>detailed function description. Could you provide a few examples of such
>functions?
You have missed the point. That is what makes such code legal.
What C99 has done is to break many of the explicit promises to the
programmer in C90, thus causing portable, conforming programs to
either be rejected or (worse) misbehave. This is one such area.
Consider:
#include <string.h>
static void *(*copy)(void *, const void * , size_t) = memcpy;
In C99, memcpy is declared as:
extern void *memcpy(void * restrict , const void * restrict , size_t);
copy(a,b,n);
Now, the assignment is legal, because of the 6.7.5.3 $15, but it is
not permitted to call copy without first casting it to
void *(*copy)(void * restrict , const void * restrict , size_t)
because of 6.5.2.2 #6.
Putting my implementor's hat on, I don't think that this example is
going to cause programs to misbehave - but I am FAR from certain
that there are no such examples, where it won't. In particular,
I know that the errno change DOES cause conforming, portable C90
programs to misbehave, with at least some valid Studio 9 options.
Regards,
Nick Maclaren.
Joerg Schilling
Roger Faulkner <roger.f...@sun.com> wrote:
>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).
...
>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).
This seems to be a feasible solution, but.....
>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()).
This leads me to the question whether the existence of <procfs.h>
is an authoritive (and OS independent) answer to the question
whether there is a procfs-II interface.
It seems that SCO UnixWare does not have <procfs.h> but only
<sys/procfs.h> and does not even include procfs-I compatibility.
So how is it possible to find whether a procfs-II interface is available?
Is it the absence of the PIO* macros?
>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).
Does this mean that a 32 bit shell cannot retrieve statistical
informations about it's 64 bit children?
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Drazen Kacar
> In article <slrncqjh0...@fly.srk.fer.hr>,
> Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> >Nick Maclaren wrote:
> >
> >> 2) If compiled in C99 mode, it must not use any of the features of
> >> C90 that are broken by C99 (e.g. it must not declare most library
> >> functions explicitly, and so may not use their addresses as variables
> >> or arguments).
> >
> >Section 7.1.4 says it's OK in general unless explicitly overriden in a
> >detailed function description. Could you provide a few examples of such
> >functions?
>
> You have missed the point. That is what makes such code legal.
I didn't manage to express myself properly. But you've answered the
question I meant to ask anyway. Thanks.
> Putting my implementor's hat on, I don't think that this example is
> going to cause programs to misbehave - but I am FAR from certain
> that there are no such examples, where it won't. In particular,
> I know that the errno change DOES cause conforming, portable C90
> programs to misbehave, with at least some valid Studio 9 options.
Because it's not required to set errno on underflow any more, or you had
something else in mind?
Nick Maclaren
In article <slrncqm10...@fly.srk.fer.hr>,
Drazen Kacar <da...@fly.srk.fer.hr> writes:
|>
|> > Putting my implementor's hat on, I don't think that this example is
|> > going to cause programs to misbehave - but I am FAR from certain
|> > that there are no such examples, where it won't. In particular,
|> > I know that the errno change DOES cause conforming, portable C90
|> > programs to misbehave, with at least some valid Studio 9 options.
|>
|> Because it's not required to set errno on underflow any more, or you had
|> something else in mind?
No, underflow is an operation-level exception, not a <math.h> one,
and isn't regarded as a critical one nowadays, anyway (but I am
not going to start THAT debate again now).
The <math.h> functions are no longer required to set errno on
error, and are now permitted to set errno invalidly even if there
is no error. As far as I know, the Solaris ones take only the
former liberty - e.g. exp(1.0e100) may not set ERANGE and sqrt(-1.0)
or atan(2.0) may not set EDOM.
Regards,
Nick Maclaren.
Daniel Berger
<snip>
>
> > 2.What is the replacement for procfs when Large file support is needed?
>
> You need to use the new (since Solaris 2.6) method of accessing procfs.
> Basically, rather than just opening /proc/PID and issuing an ioctl,
> there are various files in a directory called /proc/PID, and you open
> the one that contains the info you want. See the proc(4) man page for
> more info--or better, Chapter 8 of my book (which happens to be the sample
> chapter on the book's web site!).
>
> HTH,
There's also kvm.h, which I was surprised wasn't mentioned in your
book Rich. That, and kstat.h. (Are they?)
/me suggests adding them to the 2nd edition. :)
Actually, is /proc guaranteed to be mounted on Solaris, ala *BSD?
Regards,
Dan
Rich Teer
> There's also kvm.h, which I was surprised wasn't mentioned in your
> book Rich. That, and kstat.h. (Are they?)
Yeah, coverage of that library (among several others) had to be dropped
due to lack of space and time.
> /me suggests adding them to the 2nd edition. :)
Assuming there is one (a 2nd edition), I think a multiple volume
tome would be a better way to go!
> Actually, is /proc guaranteed to be mounted on Solaris, ala *BSD?
Yep. I guess in principle one might be able to unmount it,
but I have no idea of what breakage would happen!
Roger Faulkner
> In article <a412da98.04112...@posting.google.com>,
> Roger Faulkner <roger.f...@sun.com> wrote:
>
> >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()).
>
> This leads me to the question whether the existence of <procfs.h>
> is an authoritive (and OS independent) answer to the question
> whether there is a procfs-II interface.
Unfortunately, there is no OS independence for the /proc interface.
Every OS implements it differently, both conceptually and in detail.
The only common element is the existence of the /proc directory.
Everything else is different.
> It seems that SCO UnixWare does not have <procfs.h> but only
> <sys/procfs.h> and does not even include procfs-I compatibility.
The SCO UnixWare implementation is the closest other implementation
to the Solaris implementation (they have common roots), but it is
different in detail, as you observe.
> So how is it possible to find whether a procfs-II interface is available?
> Is it the absence of the PIO* macros?
On Solaris, the key is the the OS release number (uname -r).
Anything >= 5.6 has procfs-II; anything <= 5.5 doesn't have it.
On other OS's, you have to figure it out for yourself.
> >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).
>
> Does this mean that a 32 bit shell cannot retrieve statistical
> informations about it's 64 bit children?
The shells don't use the /proc interface to get any information
about their children. What statistical information are you referring
to anyway? AFAIK such information is obtained by running a program,
not by any shell built-in.
Roger Faulkner
roger.f...@sun.com
shea martin
>> You need to use the new (since Solaris 2.6) method of accessing procfs.
>> Basically, rather than just opening /proc/PID and issuing an ioctl,
>> there are various files in a directory called /proc/PID, and you open
>> the one that contains the info you want. See the proc(4) man page for
>> more info--or better, Chapter 8 of my book (which happens to be the
>> sample
>> chapter on the book's web site!).
After reading your chapter:
I changed <sys/procfs.h> to <procfs.h>, removed the ioctl and replaced
it with a read. But I still get a compile error stating that "procfs
cannot be used in the large file compilation environment".
What have I missed?
~S
Rich Teer
> I changed <sys/procfs.h> to <procfs.h>, removed the ioctl and replaced
> it with a read. But I still get a compile error stating that "procfs
> cannot be used in the large file compilation environment".
>
> What have I missed?
Another poster mentioned something that I can't recall right now,
but assuming the header file is correct (and I have no idea why
one can't use /proc with the large file interface, given how small
the structures are), you have three choices:
1. Put the /proc stuff in its own, non-largefile aware module.
2. Use the transitional, rather than large file, compilation
environment.
3. Compile your app as a 64-bit one.