LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.09.16 17:54 "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/