Application can crash if linked against both libppd and libcups

CUPS, on its sources, implements (duplicates implementation) of some, but not all, libppd functions, and exports them from the libcups.so library.

For example, the ppdOpenFd and ppdClose functions are exported from the libcups.so, while ppdLoadAttributes is not.

If the application is linked against both libcups.so and libppd.so libraries, the following scenario is possible:

• application calls ppdOpenFd from the libcups.so
• application calls ppdLoadAttributes, and this call is now goes into the libppd.so library. This function modifies the ppd_file_t structure, but the definition of this type is not exactly the same between these two libraries (the actual difference seems to be in the ppd_cache_t in the libppd vs _ppd_cache_s in the libcups.so)
• application calls ppdClose and this call goes to the libcups.so and crashes there in attempt to destroy the _ppd_cache_s structure, which was actually created in the libppd.so

The exact behaviour depends on a link order; if libppd is linked first, everything is OK, while if libcups is linked first, application crashed.

I've caught this issue at Fedora 40 with cups-2.4.11-1.fc40.x86_64 and libppd-2.1~b1-2.fc40.x86_64 packages installed, but most likely it may affect other distros and other version.

It is hard to say what could be a perfect solution for this problem, because libcups header files announces exporting many ppdXXX functions, so this is a part of the libcups public API. And without linking of the libcups.so the libppd.so functions that use ipp_t and ipp_attribute_t become unusable, because these types are opaque and accessible only via libcups.so-exported API...

Start by reproducing the link-order-dependent crash using ppdOpenFd, ppdLoadAttributes, and ppdClose with both libcups.so and libppd.so. Inspect the differing ppd_file_t and cache implementations, along with the libcups public API declarations. Done requires an agreed solution that prevents the mixed-library object from crashing, but the issue does not identify a specific implementation path.