Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #197053 > unrolled thread

it's a shame... python error over error

Back to article view | Back to comp.lang.python

Contents

  it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:36 +0100
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:44 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:49 +0100
    Re: it's a shame... python error over error Barry <barry@barrys-emacs.org> - 2024-12-13 18:24 +0000
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 21:56 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 08:27 -0700
    Re: it's a shame... python error over error "Peter J. Holzer" <hjp-python@hjp.at> - 2024-12-14 10:56 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-14 18:31 +0100
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-15 06:12 +1100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 22:21 -0700
    Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 08:30 -0700
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-16 08:08 +0100
      Re: it's a shame... python error over error "Peter J. Holzer" <hjp-python@hjp.at> - 2024-12-16 16:30 +0100
      Re: it's a shame... python error over error Grant Edwards <grant.b.edwards@gmail.com> - 2024-12-16 14:06 -0500
      Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-17 21:30 -0700
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-25 12:05 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-25 12:20 +0100
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-26 09:55 +1100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:34 +0100
            Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-30 17:10 +1100
            Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-30 10:29 -0700
              Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2025-01-03 23:16 +0100
                Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2025-01-04 09:25 +1100
                Re: it's a shame... python error over error (Posting On Python-List Prohibited) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-03 23:17 +0000
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-25 20:55 -0700
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:42 +0100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:47 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-25 20:57 -0700
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-26 16:46 +1100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:35 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-26 11:33 -0700
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-27 07:46 +0100

Page 1 of 2  [1] 2  Next page →

#197053 — it's a shame... python error over error

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)

[toc] | [next] | [standalone]

#197054

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.
> 

1. The build is done with my user and the installation is done as root.
2. The setup proper find *my* python3 because my PATH etc is setup well.
3. root is an other environment and root does *not* have my environment.
4. root uses *my* python3 without *my* environment and is *not* able to find
    *my* libpython3.12d.so.1.0
5. obviously the *python3* is *not* able to create the right environment from
   the installation directory of the *python3* executable.

[toc] | [prev] | [next] | [standalone]

#197055

On 13.12.24 11:44, aotto1968 wrote:
> 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.
>>
> 
> 1. The build is done with my user and the installation is done as root.
> 2. The setup proper find *my* python3 because my PATH etc is setup well.
> 3. root is an other environment and root does *not* have my environment.
> 4. root uses *my* python3 without *my* environment and is *not* able to find
>     *my* libpython3.12d.so.1.0
> 5. obviously the *python3* is *not* able to create the right environment from
>    the installation directory of the *python3* executable.

even the `sudo -E make install` with "-E, --preserve-env" does help.

[toc] | [prev] | [next] | [standalone]

#197056

> On 13 Dec 2024, at 15:54, aotto1968 via Python-list <python-list@python.org> wrote:
> 
> 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

This is a debug build?

Try setting LD_LIBRARY_PATH to point at the folder that contains the .so.
Test with `ldd python3` which will show which .so libs python3 needs and if they are found.

This is what I see on Fedora 41 as an example of the output.

$ ldd /usr/bin/python3
        linux-vdso.so.1 (0x0000ffffb8515000)
        libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 (0x0000ffffb7ea0000)
        libc.so.6 => /lib64/libc.so.6 (0x0000ffffb7cd0000)
        libm.so.6 => /lib64/libm.so.6 (0x0000ffffb7c20000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffffb84d0000)

Barry

[toc] | [prev] | [next] | [standalone]

#197057

On 13.12.24 19:24, Barry wrote:
> 
> 
>> On 13 Dec 2024, at 15:54, aotto1968 via Python-list <python-list@python.org> wrote:
>>
>> 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
> 
> This is a debug build?
> 
> Try setting LD_LIBRARY_PATH to point at the folder that contains the .so.
> Test with `ldd python3` which will show which .so libs python3 needs and if they are found.
> 
> This is what I see on Fedora 41 as an example of the output.
> 
> $ ldd /usr/bin/python3
>          linux-vdso.so.1 (0x0000ffffb8515000)
>          libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 (0x0000ffffb7ea0000)
>          libc.so.6 => /lib64/libc.so.6 (0x0000ffffb7cd0000)
>          libm.so.6 => /lib64/libm.so.6 (0x0000ffffb7c20000)
>          /lib/ld-linux-aarch64.so.1 (0x0000ffffb84d0000)
> 
> Barry
> 
> 

the problem is *not* to setup an environment variable, the problem is that python is *not*
able to setup the *python* environment by it self.

[toc] | [prev] | [next] | [standalone]

#197062

On 12/13/24 1:56 PM, aotto1968 via Python-list wrote:
> the problem is *not* to setup an environment variable, the problem is that python is *not*
> able to setup the *python* environment by it self.

You're mistaken in this case.  Nothing you've posted indicates the
problem is in Python itself.  Something isn't quite right with your
linker and the linker search paths.  LD_LIBRARY_PATH is one way to force
the linker to use the correct search path.

Python has no direct influence over the linker search paths, other than
to list what shared libraries it is linked against, or to manually add
paths to the linker in /etc/ld.so.conf.d/ during package installation.
The ld.so linker is responsible for finding the files and linking them
in, not Python. In your case it seems unable to do so, for whatever
reason. Since your custom version of python3 does seem to link to the so
properly, it seems as though something isn't right in the environment of
the mono build process.  Again, nothing to do with Python.  The linker
isn't even getting to the bit where it links in libpython3.

[toc] | [prev] | [next] | [standalone]

#197060

[Multipart message — attachments visible in raw view] — view raw

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

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

[toc] | [prev] | [next] | [standalone]

#197064

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.

[toc] | [prev] | [next] | [standalone]

#197065

On Sun, 15 Dec 2024 at 06:05, aotto1968 via Python-list
<python-list@python.org> wrote:
> 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.
>

So, it's an environment problem, NOT a Python problem. You messed up
your installation. Start over, rebuild.

ChrisA

[toc] | [prev] | [next] | [standalone]

#197067

On 12/14/24 10:31 AM, aotto1968 via Python-list wrote:
> 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.

mono build is failing even before you get to running your python3.
That's not something python developers can fix.

[toc] | [prev] | [next] | [standalone]

#197063

On 12/14/24 2:56 AM, Peter J. Holzer via Python-list wrote:
> 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.

Indeed something is not right with his ld.so search paths. The original
error report indicates the linker cannot even find the libpython so
file, so this cannot be a problem with Python since the linker hasn't
even found it.  I don't see how he expects python to fix this
configuration issue magically for mono's build scripts.

[toc] | [prev] | [next] | [standalone]

#197070

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.

[toc] | [prev] | [next] | [standalone]

#197071

[Multipart message — attachments visible in raw view] — view raw

On 2024-12-16 08:08:46 +0100, aotto1968 via Python-list wrote:
> 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".
[...]
> 
> If I read the answers I come to the conclusion that the "supporters" at python

We are not "the supporters at python". None of us is paid for doing
support. Most of us are just users of Python discussing the language and
helping each other when we can (some of us are also contributors to
Python).

> doesn't ever understand the problem.

Quite possibly, but in that case you haven't explained it well enough.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

[toc] | [prev] | [next] | [standalone]

#197072

On 2024-12-16, aotto1968 via Python-list <python-list@python.org> wrote:

> If I read the answers I come to the conclusion that the "supporters"
> at python doesn't ever understand the problem.

You should definitely demand to speak to the manager and request your
money back.

--
Grant

[toc] | [prev] | [next] | [standalone]

#197075

On 12/16/24 12:08 AM, aotto1968 via Python-list wrote:
> If I read the answers I come to the conclusion that the "supporters" at python doesn't ever understand the problem.

Sorry you feel that way.  Various people gave the best advice they could
based on what you had provided.  You were given some good advice and
even a few very specific things to try to determine the root problem
which you don't seem to have done.  I've used linux for 30 years and
I've never seen a relative path used for a linker search path.  What
provided this path to the linker?

[toc] | [prev] | [next] | [standalone]

#197101

I get angry…

next python error…

1) The OpenSUSE command "cnf" checks if a special package feature is installed.
2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3 
project directory and never changed the OpenSUSE installation.
3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s 
own "Python" and "Sqlite3" software.
4) Now the "cnf" fails with "Python" which apparently tries to use **my** SQLite3.

 > what a shame.


 > cnf jmc
Traceback (most recent call last):
   File "/usr/bin/cnf", line 9, in <module>
     import scout
   File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in <module>
     import sqlite3
   File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in <module>
     from sqlite3.dbapi2 import *
   File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in <module>
     from _sqlite3 import *
ImportError: /usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_trace

[toc] | [prev] | [next] | [standalone]

#197102

On 25.12.24 12:05, aotto1968 wrote:
> I get angry…
> 
> next python error…
> 
> 1) The OpenSUSE command "cnf" checks if a special package feature is installed.
> 2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3 
> project directory and never changed the OpenSUSE installation.
> 3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s 
> own "Python" and "Sqlite3" software.
> 4) Now the "cnf" fails with "Python" which apparently tries to use **my** SQLite3.
> 
>  > what a shame.
> 
> 
>  > cnf jmc
> Traceback (most recent call last):
>    File "/usr/bin/cnf", line 9, in <module>
>      import scout
>    File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in <module>
>      import sqlite3
>    File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in <module>
>      from sqlite3.dbapi2 import *
>    File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in <module>
>      from _sqlite3 import *
> ImportError: /usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_trace
> 

It is not only an *usage* error it is also an *security* error because:

1) "cnf" is using OS python

 > head /usr/bin/cnf
#!/usr/bin/python3

import gettext
import os
...

2) os "root" python
 > ls -al /usr/bin/python3
lrwxrwxrwx 1 root root 9  2. Dez 13:16 /usr/bin/python3 -> python3.6
 > ls -al /usr/bin/python3.6
-rwxr-xr-x 2 root root 10560  2. Dez 13:16 /usr/bin/python3.6

3) using **my** local non-root library
 > ls -al NHI1_EXT/lib64/libsqlite3.so.0
lrwxrwxrwx 1 dev1usr users 19 23. Dez 22:09 NHI1_EXT/lib64/libsqlite3.so.0 -> libsqlite3.so.0.8.6
 > ls -al NHI1_EXT/lib64/libsqlite3.so.0.8.6
-rwxr-xr-x 1 dev1usr users 3851872 23. Dez 22:09 NHI1_EXT/lib64/libsqlite3.so.0.8.6

[toc] | [prev] | [next] | [standalone]

#197105

On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
<python-list@python.org> wrote:
> It is not only an *usage* error it is also an *security* error because:
>
> 1) "cnf" is using OS python
> 2) os "root" python
> 3) using **my** local non-root library

Yes. And YOU were the one who installed a new root Python. This is a
feature. You have the power to update Python on your system.

You managed to make a build of Python that attempts to link to a DLL
using a relative path. That's a fault of the build that means it won't
work as root. I don't understand the confusion here; isn't the
solution here to build a new version with an absolute path, and update
your installation?

ChrisA

[toc] | [prev] | [next] | [standalone]

#197109

On 25.12.24 23:55, Chris Angelico wrote:
> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
> <python-list@python.org> wrote:
>> It is not only an *usage* error it is also an *security* error because:
>>
>> 1) "cnf" is using OS python
>> 2) os "root" python
>> 3) using **my** local non-root library
> 
> Yes. And YOU were the one who installed a new root Python. This is a
> feature. You have the power to update Python on your system.
> 
> You managed to make a build of Python that attempts to link to a DLL
> using a relative path. That's a fault of the build that means it won't
> work as root. I don't understand the confusion here; isn't the
> solution here to build a new version with an absolute path, and update
> your installation?
> 
> ChrisA

sorry you don't understand the problem…

 > You managed to make a build of Python that attempts to link to a DLL

I never touch the OpenSUSE python. the OpenSUSE python try to use my
sqalite3.

[toc] | [prev] | [next] | [standalone]

#197122

On Mon, 30 Dec 2024 at 15:02, aotto1968 via Python-list
<python-list@python.org> wrote:
>  > You managed to make a build of Python that attempts to link to a DLL
>
> I never touch the OpenSUSE python. the OpenSUSE python try to use my
> sqalite3.

You keep saying this, but do you even know what "make install" does?

Are you capable of admitting that you were wrong, or are you going to
keep digging this hole?

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web