|go text: || - index - problems - systems - libraries - converting - programming - old library - [ new library ] - links -
||topics: || - dual export - largefiles win32 - compat32 calls - [ compat32 library ] - long32 dualmode -

compat32 library

During the creation of the compat32 calls one might put them near their originals that are supposed to be compiled as largefile64 functions. However one might want to push developers a little bit stronger into the direction of compiling with largefile64 enabled. This can be achieved my moving the long32 calls into a separate library.

The declarations in the header file would be moved to another one that could be installed like /usr/inlude/mylib32.h next to the normal headers of /usr/include/mylib.h which are supposed to represent largefile64 calls. The extra long32 header file would look like

#include "mylib.h"
extern long myseek32(int fd, long pos, int whence);

Likewise the implementation would be moved to a seperate file like mylib32.c - compile them and link them to a separate library that would be named like "libmylib32.so" and which has an rpath dependency on the original largefile64 "libmylib.so".

During the installation you could also add a pkgconfig scriplet where your "mylib32.pc" has a dependency on "mylib.pc" which is something like..

  Name: My Lib
  Description: My Test Library
  Version: 0.0.1
  Cflags: 
  Libs: -lmylib32
  Requires: mylib

During compilation this would be expanded into "-lmylib -lmylib32" for anyone that compiles for mylib32 and the requirement for that is obvious as soon as the developer picks up any library function that ends with "32". Of course, all those "32" would really be 64-bit functions on a 64-bit system but this behaviour is pretty well known to win64 developers. The "32" is more of a hint to be "compatible with" the good old long32 world.