The last week we once again run into an issue with the Linux shared library loader. In a Xojo app you may end up having several libraries several times in different versions. For example the system provides the zlib library in some version, e.g. 1.2.3 on an older Linux installation. The MBS Compression Plugin uses zlib in version 1.2.8 while DynaPDF uses a custom patched 1.2.7 for the PDF compression. Also the Xojo runtime may come with its own version.
Now it seems like there can be a problem. All those versions of the library may or may not export publicly their functions and you may have several deflateInit functions around. Now when resolving the functions references in a shared library (e.g. plugin), the loader will pick one by name to solve it. And for us this was catastrophic a few times. Because you end up getting a different version of the library than expected. DynaPDF brings 1.2.7, but may end up getting tied up to 1.2.3 or 1.2.8. For PNG, JPEG, zlib and other libraries, there are checks in place to make sure the header files and the library matches in version. If versions won’t match data structures may have different sizes or parameters to functions have different meanings.
In DynaPDF the resulting error from a different zlib version is:
'EndPage: Error compressing stream!' (code:14, type:536870912)
This is solved for MBS Plugin 17.3pr4 by setting all non-exported symbols to local symbols. This should make all functions to resolve within the library take precedence over functions from other libraries.
For DynaPDF we added GetPNGVersion, GetJPEGVersion, GetTIFFVersion and GetZlibVersion functions. They allow you to query the jpeg, png, tiff and zlib versions used in the DynaPDF library.
PS: For FileMaker Cloud we do the same fix next prerelease.