need advice on library interface
libsndfile is close to making a 1.0.0 release. As the new maintainer of
the libsndfile Debian package and as an upstream author for software that
uses libsndfile, I'm working with the libsndfile author to iron out all
the remaining issues with his release candidates.
We've encountered a problem that involves LFS. libsndfile 1.0 supports
LFS, and since libsndfile's interface includes operations like seeking on
a sound file, some of the functions in his external interface take
parameters of type off_t. He compiles libsndfile with
_FILE_OFFSET_BITS=64, which makes off_t 64 bits. He then adds
_FILE_OFFSET_BITS=64 to the CFLAGS of client programs (using pkg-config),
to ensure that off_t is recognized as 64 bits when compiling the client
program.
This caused a problem for me when I tried to link against wxWindows,
which *also* includes off_t in its interface but *doesn't* compile with
_FILE_OFFSET_BITS=64.
As I thought about it more, this seems to cause a more general problem
that the ABI of a library that uses off_t in its interface is not stable,
since function signatures vary based on whether LFS is supported and
compiled in.
I can think of only two solutions:
1. fix the ABI to use 64 bits in all cases. Drawbacks:
- if LFS support was not compiled in, values are silently
truncated internally.
- the author tells me that libsndfile is portable to many
systems he does not have access to, and there is no
universal way to declare a 64-bit datatype.
2. define two functions for every API function: a 32-bit version
and a 64-bit version. Substitute in the 64-bit version with
the preprocessor if _FILE_OFFSET_BITS=64 is defined.
Drawbacks:
- PITA
- if libsndfile was not compiled with LFS support but
the client application is, there will be linker errors
when the linker cannot find the 64-bit functions. This
seems minor though: if LFS is supported on a target platform,
it will probably be compiled in.
How should this be solved?
Josh
--
Joshua Haberman <joshua@haberman.com>
Reply to: