> I need to write a program to make a file larger than 2 GB using Solaris
> 2.6.
> I can create a large file by "cat"ing two 2 GB files together. Solaris
> has no
> problem with this.
> When I try to write a C program, using gcc or sun native compilers, the
> program
> generates errors when trying to write records out past the 2 GB
> barrier. I think this
> is because my libraries are still using a signed long (32 bit) to
> maintain position in the file.
> Does anybody know of a compiler that doesn't have this restriction? (or
> has updated
> libraries)
> --- OR ----
> Is it just a configuration error with my compiler?
You need to read the lfcompile(5) and lfcompile64(5) manpages.
Standard compilation env is all 32-bit, so off_t is signed 32-bit
and you can't get beyond 2Gb.
If you have private libraries that have 32-bit off_t's etc
"burned in" then you've got more work on your hands :-)
Transitional environment (lfcompile64(5)) is most easily
enabled with _LARGEFILE64_SOURCE=1 before #includes (or on
compile line). This exports both xxx() and xxx64() versions
of all library and system calls that are concerned with
file offsets (open, lseek etc). It's not the preferred
environment if you can work with the largefile API instead,
but can be used as a quick way of making and application
largefile aware. Code looks ugly because there are
xxx64() calls littering it. Some components of the OS
require this environment --- eg, if you're working with
procfs, /dev/kmem etc.
The largefile API (lfcompile(5)) is enabled with _FILE_OFFSET_BITS=64.
xxx64() calls are not exported (so you can't use this form in
source) but xxx() calls are internally mapped to the xxx64() 64 bit
form.
Last note: if you're just experimenting with largefiles and
don't really care what the content is, use holey files
larger than 2Gb --- you don't need gigabytes of diskspace
to play then.
Cheers
Gavin
by