OpenRV loads libpng 1.5 before 1.6, which breaks io_png plugin

[chadrik]

Hi all,
We ran into an issue with load order between the system libpng 1.5 and libpng 1.6 that is built for OpenRV.
​
In the commercial RV distribution (2022.3.1), rv.bin links directly against libpng16.so. However, the rv.bin that is produced by the OpenRV build does not directly link against libpng at all. The end result of this is that when OpenRV runs, it ends up loading libpng15.so (as a side-effect of loading its dependencies) before libpng16.so. Since multiple versions of libpng cannot coexist within the same symbol namespace, this load order breaks the functionality of the io_png plugin, since it apparently relies on some specific features/functionality of the newer png library version.

The end result is that OpenRV cannot read PNG files, instead producing these warning error messages when trying to load them:
​

libpng warning: Application built with libpng-1.6.20 but running with 1.5.13
ERROR: plugin 'IOpng' cannot read '/path/to/image.png': PNG: error creating read struct /path/to/image.png
INFO: trying brute force to find an image reader for image.png

​
Using LD_PRELOAD to force-load libpng16.so in OpenRV fixes this error, which confirms that the library load order is important to allowing RV to function correctly.

It seems like the solution would be to ensure that rv.bin links directly against libpng16.so, but we have not tested this yet, as we're getting by with LD_PRELOAD.

CentOS 7.8.2003
OpenRV runtime version info: Version 2023.0.0, built on Feb 1 2023 at 11:45:25 (HEAD=9c6adc2).

Looping in @nrusch who did the investigation on our side.

[geffrak]

Good catch @nrusch, and thanks for the clear report @chadrik.

The reason why the behaviour is different between RV 2022.3.1 and OpenRV is that the build system is 100% different, and this issue went unnoticed while testing it with our internal OpenRV CI setup.

We will try to find some time to fix it soon. Here's the Github Issue for the work item. I'm locking this discussion so we don't discuss the issue at two places.