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 Guido U. Draheim |
Providing LARGEFILE64_SOURCEIn 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 |