printer / text mode version largefile64_source

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) 2010-03-27 <guidod>
 Guido U. Draheim

Providing LARGEFILE64_SOURCE

In general a dualmode library will only document a single function call synopsis in the header files. It merily depends on the RENAMEs whether that call symbols will end up being linked to the largefile64 implementation variant of the long32 variant as it was defined in the dualmode sources before. This will basically look like this:

   #if _FILE_OFFSET_BITS+0 == 64 || defined _LARGE_FILES
   #define my_seek my_seek64
   #endif

   off_t my_seek(MYHANDLE fp, off_t offset, int whence);

If you are really adventurous then you may make both symbols visible to the application when the application code has compile with some _LARGEFILE64_SOURCE cpp define somewhere.

   #if _FILE_OFFSET_BITS+0 == 64 || defined _LARGE_FILES
   #  define my_seek my_seek64
   #endif
   
   extern off_t my_seek(MYHANDLE fp, off_t offset, int whence);

   /* which requires the symbol exist - so assuming a largefile64 binary here */
   #if defined _LARGEFILE64_SOURCE 
      extern off64_t my_seek64(MYHANDLE fp, off64_t offset, int whence);
   #endif