Current `build.sh` script links `libffi.so.7` to `libffi.so.8.1.2`, causing libGL errors with `libLLVM`

[joshuacwnewton]

In the build.sh script, there is some backwards-compatibility linking done here:

https://github.com/AnacondaRecipes/libffi-feedstock/blob/51c485b94e09cdd4bd6550dea0c5bd0b06a8488a/recipe/build.sh#L58-L69

On my machine, this results in the following linking:

> ls -lah lib | grep libffi
lrwxrwxrwx  1 joshua joshua   15 Jun  2 12:26 libffi.7.so -> libffi.so.8.1.2
lrwxrwxrwx  1 joshua joshua   15 Jun  2 12:26 libffi.8.so -> libffi.so.8.1.2
-rw-rw-r--  2 joshua joshua  96K Jun  2 12:26 libffi.a
lrwxrwxrwx  1 joshua joshua   15 Jun  2 12:26 libffi.so -> libffi.so.8.1.2
lrwxrwxrwx  1 joshua joshua   15 Jun  2 12:26 libffi.so.7 -> libffi.so.8.1.2
lrwxrwxrwx  1 joshua joshua   15 Jun  2 12:26 libffi.so.8 -> libffi.so.8.1.2
-rwxrwxr-x  2 joshua joshua  71K Jun  2 12:26 libffi.so.8.1.2

Because libffi.so.7 is linked to libffi.so.8.1.2, I now encounter the following errors on my Debian 11 machine when trying to launch a PyQt application that relies on libLLVM 11:

libGL error: MESA-LOADER: failed to open iris: /lib/x86_64-linux-gnu/libLLVM-11.so.1: undefined symbol: ffi_type_sint32, version LIBFFI_BASE_7.0 (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /lib/x86_64-linux-gnu/libLLVM-11.so.1: undefined symbol: ffi_type_sint32, version LIBFFI_BASE_7.0 (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /lib/x86_64-linux-gnu/libLLVM-11.so.1: undefined symbol: ffi_type_sint32, version LIBFFI_BASE_7.0 (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast

These specific errors were also reported on Ubuntu 20.04 with libLLVM==12, so this doesn't seem to be entirely specific to my setup, either:

• https://github.com/PaddlePaddle/PaddleOCR/issues/9108

[joshuacwnewton]

Note: If I instead install libffi from conda-forge instead (3.4.2), I see the following:

> ls -lah lib | grep libffi
-rw-rw-r--  2 joshua joshua  75K Nov  9  2021 libffi.a
lrwxrwxrwx  1 joshua joshua   15 Jun  2 13:06 libffi.so -> libffi.so.8.1.0
lrwxrwxrwx  1 joshua joshua   15 Jun  2 13:06 libffi.so.8 -> libffi.so.8.1.0
-rwxrwxr-x  2 joshua joshua  50K Nov  9  2021 libffi.so.8.1.0

And I see no errors.

The conda-forge feedstock maintainer (I think?) has confirmed that this is a defaults-only issue: https://github.com/conda-forge/libffi-feedstock/issues/46#issuecomment-1607751709

[RomeshA]

This has caused a different issue for me where group information (e.g., import grp; grp.getgrall()) does not correctly access databases outside of /etc/group (e.g., those that are in aad). On my system, in a clean Anaconda environment installing Python has libffi.so.7 -> libffi.so.8.1.2 and libffi.7.so -> libffi.so.8.1.2. If I obtain a copy of libffi.so.7.1.0 from an earlier version of libffi and change the symlinks to libffi.so.7 -> libffi.so.7.1.0 and libffi.so.7 -> libffi.so.7.1.0 then grp.getgrall() works as expected. For this use case, the issue can also be fixed by deleting libffi.so.7 and .libffi.7.so (which is more in line with what would happen if installing via conda-forge)

At the very least, it appears that libffi.so.8 and libffi.so.7 are not directly interchangeable and linking libffi.so.7 to libffi.so.8.1.2 does cause problems