Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: aotto1968 <aotto1968@t-online.de>
Newsgroups: comp.lang.python
Subject: Re: it's a shame... python error over error
Date: Sat, 14 Dec 2024 18:31:22 +0100
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <vjkfda$3cjs$1@dont-email.me>
References: <vjh2mh$3bu1o$1@dont-email.me>
 <20241214095657.s3solqdmwulqqhvt@hjp.at>
 <mailman.1.1734170821.2912.python-list@python.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 14 Dec 2024 18:31:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ff4258e3736aeb46f8d99f1d49cf73b7";
	logging-data="111228"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Hp6l2BiKottOHAt+3YibPez+1ERR8SvM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZetM8atzQ9S73XbiRXlR7EZwq38=
In-Reply-To: <mailman.1.1734170821.2912.python-list@python.org>
Content-Language: en-US
Bytes: 3996

On 14.12.24 10:56, Peter J. Holzer wrote:
> On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list 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
> 
> What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is
> HOME/src/mono.git/acceptance-tests trying to use it?
> 
> [...]
>> 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)
> 
> So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find
> HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you
> invoke it from the shell (to confirm that, try actually invoking it
> instead of running ldd on it), but not when it's called from whatever
> make is doing in the acceptance-tests directory.
> 
> So it might be because it's in a different directory ("HOME/ext/..." is
> a relative path. That will not work in a different directory. Also
> "HOME" is a strange choice for a directory name. Did you mean $HOME?) or
> because the acceptance tests set up their own environment.
> 
> I'd test the first idea first. Cd into
> HOME/src/mono.git/acceptance-tests and try to invoke
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there.
> 
>          hp
> 

The CORE problem is that python3 works well in *my* environment but the
installation is done as root and root does not use *my* environment.

the mono build search for a working python3 and find *my*
 > HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
The build is fine but after switch to root for installation
 > sudo make install
the root user call *my* python3 and fail.