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 Guido U. Draheim |
Step 2: converting to largefile defaultWhen 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
Without autoconf you can place the two #define's
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. |