printer / text mode version going largefile

index
-summary
-history
-testscript
  perl / python
problems
-with callframes
-with structures
-largefile seeks
-broken builds
systems
-freeBSD/darwin
-linux/solaris
-64on32 mix
-distro makers
-win32/other (2)
libraries
-libc ..(3264)
-zlib ..(-32-)
-gtk2 ..(-64-)
converting
-old non-off_t code
-going largefile
-longlong default
-face dualmode
-make twinlibs
-and defend (it)
programming
-largefile default
-off_t in headers
-make export64
-find mismatch
-the autowrappers
-environ changes
-best practice?
old library
-dualmode renames
-the extra function
-largefile64_source
-glibc headers
-libgz example ***
new library
-dual export
-largefiles win32
-compat32 calls
-compat32 library
-long32 dualmode
links
-some quotes
-sitemap / mpl
-large.file Group*
-ac-archive Site*

 

 

 

(C) 2003-12-20 <guidod>
 Guido U. Draheim

Step 2: converting to largefile default

When your software is portable to systems using any variant of off_t then you can put in the next step: to enable largefile by default. This is easy for software which is not a library and atleast safe with libraries that do not export a file seek-value or file descriptor.

With autoconf, include additionally AC_SYS_LARGEFILE into your autoconf script. In conjunction with AC_FUNC_FSEEKO and AC_TYPE_OFF_T it will ensure that any system with a largefile kernel will export a 64bit off_t to applications. As good rule of thumb all systems since the late 1990ies have a largefile kernel, and systems later than 1998 guarantee that in the product description.

Without autoconf you can place the two #define's -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 somewhere in your build environment. Those defines come from the LFS standard included in the Unix98 specification of required features. In 64on32 systems they will magically make source code with "ftell(x)" link to "ftell64" for real. On win32 system you need to add that magic manually in the application headers.

After that, your application uses largefile whereever available and portably. If you make up a library however that exports a file seek-value or a file descriptor then you need to heed on to the next steps of conversion. Otherwise you'd need to be ready to face problems when bringing your library into a production cycle.

 

If you converted an executable then you are done. If you converted a library and no binary-compatibility is needed and no plugins are ever bound late then you are done as well. Otherwise you need to seek binary-compatibility and in the course to decide about dualmode or twinlibs. Using twinlibs is recommended strongly but dualmode is about the only option when mixing multiple libraries of a different off_t format.