On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-library
proper __or__ switch to a *static-build* by default.
-> example here is the "mono-build" with the following installation.
make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared libraries: libpython3.12d.so.1.0: cannot open
shared object file: No such file or directory
make[2]: Für das Ziel „install-exec-am“ ist nichts zu tun.
make[2]: Für das Ziel „install-data-am“ ist nichts zu tun.
make[2]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
[debug]dev1usr@linux02:~/src/mono.git> ldd
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
linux-vdso.so.1 (0x00007ffd18e9a000)
libpython3.12d.so.1.0 =>
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0
(0x00007f9c5d374000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000)
libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000)
If I read the answers I come to the conclusion that the "supporters" at python
doesn't ever understand the problem.
--
https://mail.python.org/mailman/listinfo/python-list
