Problems In Virtual Environment - SUDO and NUMPY

I’m running a Waveshare 2.13 eIink HAT on a RPI Zero W running 32 bit Bullseye Lite.

I am following the RPI Setup Instructions with the deviation I set up a Python Virtual Environment. So I ran the script as sudo ~/tpcc_venv/bin/python This returned the infamous NUMPY error “ cannot open shared object file”.

On the chance there was an issue between SUDO, some of the software and VENV, I created a new user and reran the tests, without a virtual environment, and it worked.

There are a lot of complicated pieces here that I don’t understand, and, this is my first attempt at building a Python project inside a VENV. I’m looking to see if anyone has any guidance.


You may need to set LD_LIBRARY_PATH to include the dir where is located so that it can be found.

Thanks @barry-scott but how is one to know to set LD_LIBRARY_PATH when working in VENV? Remember, this demo works outside of VENV but not inside it. LD_LIBRARY_PATH is not set inside or outside if VENV on my RPI.

Your problem is mysterious to me. A python venv is essentially nothing more than a directory tree, containing a Python executable (plus corresponding special lib dependencies and support files, etc) plus a set of (active) environment variables (making that Python executable the default one). Once you have activated the venv (basically by exporting those env variables), you don’t have to (and should not) use “sudo” to run python. (I don’t know specifics about the PI, but I believe this also applies at least to the “Bookworm” release.)

That implies that by setting LD_LIBRARY_PATH, as @barry-scott suggested, you can make any library available that is not somehow also by default accessible. What I don’t understand is why (which would be installed in some system dir and should in principle also be accessible in the venv) couldn’t be opened. My guess is that there is some mismatch with required versions or with expected filenames – so something may not have been setup correctly when you created the venv.

When you followed the original TP_lib setup, did you make sure to use python3?
How did you set up your Python virtual env? Did you also make sure to use python3? Are you using the latest version of numpy and did you install it with your venv activated?

1 Like

Its the standard linux way to fix a problem with a program is not able to find .so files that are not in a standard location. As @hansgeunsmeyer says it is odd that you would need to do this.

Did if work to define this variable? If so then we can try to figure out why it was needed.

Thanks @hansgeunsmeyer. As to you questions:

  • “… you don’t have to (and should not) use “sudo” to run python.” The instructions say to use SUDO and I get other errors if I don’t. I don’t understand what’s happening under the covers but SUDO is needed.
  • "…did you make sure to use python3? "I’m just using python but it shows as being 3.9.2
  • “How did you set up your Python virtual env?” I think it was python -m venv tpcc_env
  • “Are you using the latest version of numpy and did you install it with your venv activated?” There’s two parts 1) sudo apt-get install python3-numpy and 2) pip install numpy and I did this in the VENV.

Issues with numpy are not new and I followed the guidance found in Troubleshooting page.

Again, it works, just not in VENV. I’ll try setting LD_LIBRARY_PATH when I get a chance

1 Like

If you are running on the Bookworm OS (don’t know if you are), then sudo should not be needed for running python (for installing basic libs perhaps when you do an apt get install, but not when running python or pip itself). At least that’s what I get from Raspberry Pi Documentation - Raspberry Pi OS (none of the instructions using python there use sudo).

If you have already installed packages and want to make them available in the venv, then it seems you need to set up the venv with:

If you want to inherit the currently installed packages from the system Python, you should create your virtual environment using python -m venv --system-site-packages env .

So, perhaps that’s also one thing to try.

Thanks for all the suggestions.

I went looking for but couldn’t find it.Since It’s listed as a shared object so maybe it’s transient.

Unfortunately, since I’m dealing with a software vendor (WaveShare) who didn’t include instructions for running inside VENV, and I can run outside of it, I’m going that root.

Personally. having run into numpy issues before, this is far to complex for me to work on but I wanted to let the community know.

Thanks again

If that typo was deliberate, then it was very germain

:rofl: Too funny. Dam ( :slight_smile: ) English language; meant ‘route’.