2012.07.30 23:45 "Re: [Tiff] What about hiding not-officially-exported functions?", by Tom Lane
On 07/29/2012 03:51 PM, Tom Lane wrote:
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.
I experimented with applying a symbol filter in libtiff.map, using the current contents of libtiff.def as the list of allowed symbols.
The first thing I found out was that the tools/ build fails unless _TIFFCheckMalloc is added to the list. Not sure if we wish to do that, or adjust the tools files that have grown dependencies on it.
The second thing I found out was that the regression tests fail unless TIFFCreateEXIFDirectory, TIFFCreateCustomDirectory, TIFFWriteCustomDirectory, and _TIFFRewriteField are added to the list. The first three of these of these I guess are supposed to be exported, which means we've been sloppy about maintaining libtiff.def, and somebody ought to go through tiffio.h line-by-line to make sure all public symbols are really listed (I haven't done this). I'm not sure if it's a good idea for the regression tests to depend on _TIFFRewriteField or not --- thoughts?
After making those additions, I had a working build of libtiff, and I tried rebuilding all 109 packages that depend on it in current Fedora. The good news is they all rebuilt. The bad news is that that includes freeimage, which has a call on _TIFFDataSize. After some investigation I found out that that was because the call occurs in code that is built into a shared library, and the default switches for the GNU linker are such that it doesn't complain about unresolved symbols at link time if the references are going to be in a shared library :-(. So that makes the other 108 successes somewhat questionable; there might well be calls in there that would only fail at runtime. I don't have the time to try to figure out how to inject -Wl,-z,defs into all those builds to catch such problems. The best I can say is that the open-source world seems to *mostly* not have tried to call any non-exported functions.
Given this, I'm not going to risk sneaking a symbol filter into Red Hat's 4.0 release. I think we should consider adding one at the next major library release, though.
regards, tom lane