2004.09.14 11:06 "[Tiff] Calltype support", by Martin Schramm

2004.09.16 17:54 "[Tiff] versioned symbols [Was: Calltype support]", by Jay Berkenbilt

But we do maintain a libtiff.def already to keep the list of functions to be exported. The issue in question is calling conventions which is in addition to the issue of controlling what gets exported.

The libtiff.def approach is easier for the library maintainer but it is invasive for the library user. DLL exported functions should be __declspec(dllimport) by default so that library users don't need to know if they are using a DLL. This can be accomplished with appropriately "decorated" header files.

I think I'm straying off topic, but only slightly. Is the next version of libtiff going to support versioned symbols in the UNIX version of the shared library? This is something I was planning to address for Debian -- having versioned symbols in the library (reasonably straightforward to support with libtool) makes it possible to deal with a situation where application A uses libtiff directly and also uses library B which also uses libtiff, even when application A and library B were compiled with different versions of libtiff. (Consider, for example, vips which uses libtiff directly but also links with libmagick which also uses libtiff.) It seems that, with the migration of the build system to libtool and the separation of the soname from the software version, now would be the right time.

I'll be taking over as debian maintainer for libtiff and was planning on tackling this at some point anyway. If it would be useful, I can try to do it in time for the next libtiff release if it isn't already being done. (To be honest, I'm not yet sure what exactly is involved in doing this, but I know what questions to ask and what to read, and I'm certain that I'll be able to figure it out.)

--Jay

Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/