python3-magic uses ctypes.util.find_library('magic') , which actually uses `ldconfig -p` to find installed libraries. That's not honoring the LD_LIBRARY_PATH and it is getting your host-installed library list. With the "fake" hit of your host's /usr/lib/<arch-triplet>/libmagic.so.1 (which gets distilled down to "libmagic.so.1"), it ends up loading the library fine afterwards.
So, in short:
(1) ctypes.util.find_library() is currently broken for snaps.
(2) I don't know that it's an issue, but I wonder if the host ldconfig cache shouldn't be leaking for strict snaps? In this case, it's clearly triggering system-specific behavior changes...
python3-magic uses ctypes. util.find_ library( 'magic' ) , which actually uses `ldconfig -p` to find installed libraries. That's not honoring the LD_LIBRARY_PATH and it is getting your host-installed library list. With the "fake" hit of your host's /usr/lib/ <arch-triplet> /libmagic. so.1 (which gets distilled down to "libmagic.so.1"), it ends up loading the library fine afterwards.
Related: https:/ /forum. snapcraft. io/t/issue- when-snap- uses-pythons- ctype-util- find-library/ 9690
So, in short: util.find_ library( ) is currently broken for snaps.
(1) ctypes.
(2) I don't know that it's an issue, but I wonder if the host ldconfig cache shouldn't be leaking for strict snaps? In this case, it's clearly triggering system-specific behavior changes...
If `ldconfig` were to provide the correct library list in a snap, it would presumably address this without having to patch ctypes. Something like what is discussed at: https:/ /forum. snapcraft. io/t/effects- of-dynamic- library- caching- on-snap- startup- performance/ 14454