2018.07.28 13:28 "Re: [Tiff] libtiff (v3 / v4) maintain/use shared global state?", by Bob Friesenhahn

Question: Does libtiff attempt at maintaining any sort of shared global state among the DSOs dynamically referenced by the same process?

Libtiff does still use a small number of global variables related to error/warning reporting (e.g. callback registrations).

Background: I'm working on a plugin (C++) that ends up indirectly pulling in 2 different versions of libtiff (library X dynamically linked against libtiff v3.9.4 and library Y against libtiff v4.0.7) into the run-time environment through two 3rd party dependencies, which results in a segmentation fault crash due to a missing symbol (TIFFFindFieldInfo).

Considering I can rebuild X and Y from source, but modifying the source is not an option, I tried to statically link libtiff v3.9.4 into library X to make all the libtiff symbols it needs locally available, which avoids the crash; I've been testing this for some time and can confirm this solves the missing symbol problem.

Good.

The only concern I have is whether or not libtiff maintains some sort of a global state which may be shared among all libtiff users (DSOs) referenced by the same process. If this is not the case, then I can go with the static linkage solution, otherwise it is probably not safe.

If it appears to work, then you are likely ok. An issue with dynamic linkage is that you were likely getting a mix of symbols from both libraries. This would cause a severe problem since the two libraries are quite different. You may be able to fully static link your "library X" to assure that it is using the few globals from libtiff v3.9.4 and avoid the risk of the run-time linkage picking globals from the wrong library.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/