[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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.
      	- 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?


Joshua Haberman  <joshua@haberman.com>

Reply to: