Date: Mon, 06 Jun 2022 17:18:52 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264458 --- Comment #14 from John Hein <email@example.com> --- (In reply to Graham Perrin from comment #12) Are you saying that you are getting the following message still... Shared object "libffi.so.7" not found, required by "_gi.cpython-38.so" ... with the ldd -a output you attached (attachment 234479)? Given that _gi.cpython38.so does not show any reference to libffi.so.7 in your ldd output, then those two data points (the error message and the ldd output) seem to be in conflict with each other. There are ways to force references to libffi.so.8 point to libffi.so.7 instead (e.g., libmap.conf, path to alternate libs being used - like in /usr/local/lib/compat, etc.). But I am assuming you don't have anything unusual like that. By the way, just for testing, I have a backup package of python38 that was built against libffi.so.7 (the only shared object that references libffi is /usr/local/lib/python3.8/lib-dynload/_ctypes.cpython-38.so). I used that with the other dependencies (_gi.cpython-38.so, etc.) updated to the latest (all referencing libffi.so.8), and meld worked fine, even with no libffi.so.7 available. So, as far as I can see, for your originally reported issue, it should not matter if you missed an update to python38 (some comments in this thread were suggesting that as a possible issue). If you are still seeing issues, you could run 'ktrace -id /usr/local/bin/meld', and analyze the kdump output and/or attach the result here. The ktrace file would give an indication what might still be triggering the attempt to link with libffi.so.7 -- You are receiving this mail because: You are the assignee for the bug.