OMXPLAYER on Bullseye fresh install (32-bit)

OMXPLAYER doesn’t work on Bullseye fresh install. After installing the package:

$ apt install omxplayer

running the command:

$ omxplayer my-video.mp4

results in:

/usr/bin/omxplayer.bin: error while loading shared libraries: libvcos.so: cannot open shared object file: No such file or directory

That’s because Bullseye doesn’t install raspberrypi firmware on /opt/vc/lib anymore. This didn’t happened on Buster.
So, putting libraries /opt/vc/lib from raspberrypi firmware in /opt/vc/lib solve the issue and omxplayer is playing back again.

Could someone tell me if there is any “cleanest” way to install those libraries in /opt/vc/lib instead of “manually” copying those files? Is any package installation that provides this operation?

Thanks in advance for your comments.

Basically same as this https://dietpi.com/forum/t/solved-minidlna-stop-working-after-updating-to-dietpi-7-5-2/5703/2

RPi Devs changed package structure an this is causing incorrect libraries name

Using:

cd /usr/lib/arm-linux-gnueabihf
ln -s libmmal_core.so.0 libmmal_core.so
ln -s libmmal_util.so.0 libmmal_util.so
ln -s libmmal_vc_client.so.0 libmmal_vc_client.so
ln -s libbcm_host.so.0 libbcm_host.so
ln -s libvcsm.so.0 libvcsm.so
ln -s libvchiq_arm.so.0 libvchiq_arm.so
ln -s libvcos.so.0 libvcos.so

cause:

/usr/bin/omxplayer.bin: error while loading shared libraries: libbrcmEGL.so: cannot open shared object file: No such file or directory
/usr/bin/omxplayer.bin: error while loading shared libraries: libopenmaxil.so: cannot open shared object file: No such file or directory
/usr/bin/omxplayer.bin: error while loading shared libraries: libbrcmGLESv2.so: cannot open shared object file: No such file or directory

So I still need to copy these three libraries to /opt/vc/lib/

maybe the sym link to be created for the other 3 libraries as well

Hmm, those three libraries are not part of libraspberrypi0 anymore :thinking:.

A workaround may then be to download them manually, as they are still present on the GitHub repository:

cd /usr/lib/arm-linux-gnueabihf
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/hardfp/opt/vc/lib/libbrcmEGL.so'
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/hardfp/opt/vc/lib/libbrcmGLESv2.so'
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/hardfp/opt/vc/lib/libopenmaxil.so'

It works. Thanks.
But I decided to install the VideoCore - EGL/GLES/OpenVG version.
So, final solution after installing Omxplayer on fresh install:

cd /usr/lib/arm-linux-gnueabihf
ln -s libmmal_core.so.0 libmmal_core.so
ln -s libmmal_util.so.0 libmmal_util.so
ln -s libmmal_vc_client.so.0 libmmal_vc_client.so
ln -s libbcm_host.so.0 libbcm_host.so
ln -s libvcsm.so.0 libvcsm.so
ln -s libvchiq_arm.so.0 libvchiq_arm.so
ln -s libvcos.so.0 libvcos.so
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/opt/vc/lib/libbrcmEGL.so'
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/opt/vc/lib/libbrcmGLESv2.so'
curl -sSfLO 'https://raw.githubusercontent.com/raspberrypi/firmware/master/opt/vc/lib/libopenmaxil.so'

Could be interesting to add this entry on Dietpi-Software. What do you think if I create a new Software Request on your GitHub?

I guess soon (at latest when a first Raspberry Pi OS Bullseye image is released) it will be again as simple as

apt install omxplayer

so that a dietpi-software option would be overkill :slight_smile:.

The issue may be reported here to inform the RPi repo maintainers that the package requires a rebuild: https://github.com/RPi-Distro/repo/issues
Probably they know already, but it doesn’t hurt.

I found this report:
https://github.com/RPi-Distro/repo/issues/134
which is related with this issue.

As you mentioned before, libraspberrypi0 doesn’t install those libraries anymore because they are installed by rpi-update now.

So, it is not an issue in RPi OS because this firmware is installed by default on RPi OS and already contains these libraries.

One solution could be install rpi-update and running it, but as you can see here this is certainly not safe (i guess because of different kernel)

I’m not going to fully agree on your conclusion. Because rpi-update us going to install thinks like beta kernel. It’s not recommended if not really needed.

DietPi themselves did not have own kernel as DietPi is based on Raspberry OS. Hence it is exactly the same kernel.

Installing rpi-update on Dietpi fresh install (7.6.2) solve the issue, but many errors loading modules during installation (depmod errors) and other non-needed additional libraries are installed. So, I prefer to stay with this solution above to maintain a cleaner installation and not be bloated by rpi-update.
Would be great if the entry is created on Dietpi-Software (the installation of omxplayer would be more convenient for anyone).
Anyway, the solution is now here for anyone.

Makes sense, as rpi-update still installs the VC userland tools and binaries to the old path.