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-28 Guido U. Draheim |
Dualmode RenamesIf you have detected the dualmode case then you need to start renaming symbols. With the help of the C precompiler this is just a "#define". But first of all - add a define that hints the rest of your header files that the implementation code symbols are renamed. #ifdef _CONFIG_LARGEFILE_SENSITIVE # if _FILE_OFFSET_BITS+0 == 64 # define MYLIB_LARGEFILE_RENAME # elif defined _LARGE_FILES /* used on older AIX to get at 64bit off_t */ # define MYLIB_LARGEFILE_RENAME # endif #endif Actually, the wrapper ifdef on _CONFIG_LARGEFILE_SENSITIVE is not really required. In fact the GNU C library does not do so - so there will be always some "fopen64" in the library. (This might be a tribute to applications that use "dlsym" to load symbols? However the glibc has the option to set a linker alias so that it is really just a re-export of the same implementation code under a different name). The configure-check for AC_SYS_LARGEFILE_SENSITIVE has only good reason for platforms like BSD where _FILE_OFFSET_BITS==64 is always true. On those platforms it simply not required to rename the largefile version into a suffix64 symbol since it will be the only symbol to be exported. However in the following section this addition is dropped from the examples. Additionally the exampel section can be abbreviated as: /* recommended shorthand version to detect a rename-requirement */ #if _FILE_OFFSET_BITS+0 == 64 || defined _LARGE_FILES #define MYLIB_LARGEFILE_RENAME #endif With the rename-hint in place you should list all your off_t-dependent functions - and rename them to get a suffix "64". This suffix is all about traditions as they are present in the "libc" where you have "fopen64" and "lseek64". If your symbols have a natural reason for a "64" suffix (e.g. "get32" / "get64" to extract data items from a stream) then you might want to pick "_64" instead. #ifdef MYLIB_LARGEFILE_RENAME #define mylib_seek mylib_seek64 #define mylib_tell mylib_tell64 #endif Now you can write all your *.c files using a simple "my_seek" as the result code symbol in the compiled library will be exported under the name of "my_seek64". Any third-party code that is compiled with _FILE_OFFSET_BITS==32 will not be able to link to your largefile64 implementation. Therefore you have ensured that no callframe mismatch can occur. To allow those third party libaries to still compile and link succefully you have to add a second implementation like in the following page of the dualmode sources template code. Postscriptum: if you do only have one or two functions with a dependency on the "off_t" type then you could pick a shorter version of the template code. Just write the following in your header files: #if _FILE_OFFSET_BITS+0 == 64 || defined _LARGE_FILES #define mylib_seek mylib_seek64 #define mylib_tell mylib_tell64 #endif |