2012.07.29 19:51 "[Tiff] What about hiding not-officially-exported functions?", by Tom Lane

2012.07.30 12:40 "Re: [Tiff] What about hiding not-officially-exported functions?", by Jay Berkenbilt

On 07/29/2012 03:51 PM, Tom Lane wrote:

When we had the discussion of symbol versioning back in January, I had the idea that part of what was being discussed was deleting all not-officially-exported functions from the library's symbol table, so it would be impossible not just deprecated for client applications to call them. I noticed by accident that this is not in fact what was done: libtiff.map and libtiffxx.map still allow all function names to get through to the finished library. There might be a filter in effect when building on Windows; I'm not sure what the libtiff.def file is used for, but it looks like it might be intended for Windows. Nothing of the sort happens on Linux though.

Is it intentional that we're still letting clients call things like, say, _TIFFsetDoubleArray()? If not, at what point could we consider changing it? It's probably too late for 4.0, at least on distros that have already shipped that. I still have a bit of a window to apply a filter for Red Hat's distribution of 4.0, though.

Debian hasn't fully transitioned either, though tiff 4 is available. If previously exported symbols disappear from the interface, that requires an soname bump, so we would have to go to libtiff.so.6. The transition in debian to make tiff 4 the default won't occur until after Wheezy is released.

--Jay