Created attachment 227224 [details] Make libpython3.x registered by ldconfig `ldconfig -r' does not report the various libpython. The attached patch fixes the installation of the libraries for Python 3.8, 3.9 and 3.10 (maybe 3.7 could be added?). After that they are registered by ldconfig.
Thanks for the report and patch Thierry What's an example impact of this issue on consuming ports and/or users? What is the potential for regressions or affected/changed behaviour for consuming ports? If not sure, perhaps an exp-run for confidence++. Consistent changesets across all python language ports (where issue is relevent and reproducible) would be great, as would knowing explicit which *dont* require the changes and why.
(In reply to Kubilay Kocak from comment #1) ATM, I'm fighting against two ports consumers of Python: french/aster and math/sage (9.2 is OK, but I have not yet been able to upgrade it to 9.3 or the release candidates of 9.4). This patch removes some strange errors by letting them correctly be linked against the installed libpython (but other non-related problems persist). As far as I'm concerned, it does not break any ports: the visible change is that ldd will list libpython for some binaries, where it does not return anything without the proposed patch. I don't think that an exp-run is necessary in this case.
(In reply to Thierry Thomas from comment #2) Could you reference the errors for these two ports for our future selves, thanks!
Comment on attachment 227224 [details] Make libpython3.x registered by ldconfig Approved pending: - Changeset across all python ports - Confirmation of QA Please include the current impact ('strange errors') and ldconfig before/after in the commit log message as well, thanks! MFH: 2020Q3 (blanket: bugfix) Feel free to self-assign and take to resolution
(In reply to Kubilay Kocak from comment #3) Actually, these are not build errors: - when aster has been built, it is used to build a "catalog of elements", and without this patch it segfaults; - similarly, sage is used to build its internal documentation, and without this patch a segfault occurs. Both cases are hard to debug, and unfortunately I cannot explain how the registration of the Python library is related to these failures.
Committed, thanks! Note: this is not exactly the proposed patch, because my tests showed that the library name could be affected by ABIFLAGS in some cases.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=693abe1cb40ba9f505b2c72497443ca3ce85887d commit 693abe1cb40ba9f505b2c72497443ca3ce85887d Author: Thierry Thomas <thierry@FreeBSD.org> AuthorDate: 2021-10-13 16:48:56 +0000 Commit: Thierry Thomas <thierry@FreeBSD.org> CommitDate: 2021-10-13 17:05:40 +0000 lang/python3X: Fix library installation The Python ports install the library libpython3.x.so under $PREFIX/lib, and they set USE_LDCONFIG, but these libraries are not registered, due to a missing symlink, and they are not found by `ldconfig -r'. This commit make them to be registered, and for some reason it helps the dynamic linker to find them, and this allows to fix an error in french/aster. It also helps to fix errors in newer releases of math/sage (not yet ready to be committed due to other problems). No exp-run, but it has been tested with many ports on several platforms. PR: 257864 Approved by: koobs (Python team) MFH: 2021Q4 lang/python310/Makefile | 2 ++ lang/python310/pkg-plist | 1 + lang/python36/Makefile | 2 ++ lang/python36/pkg-plist | 1 + lang/python37/Makefile | 2 ++ lang/python37/pkg-plist | 1 + lang/python38/Makefile | 2 ++ lang/python38/pkg-plist | 1 + lang/python39/Makefile | 2 ++ lang/python39/pkg-plist | 1 + 10 files changed, 15 insertions(+)