It looks like you are trying to cross-compile oxmplayer. That's not necessary. What's more, it looks like you are trying to do it with the cross-compiler intended for the ARMv6 single core Pis (A/B/+/0). This will probably be okay on Fedora ARM, which is ARMv7 -- hence can't be used on those models, but is backward compatible with the software created for them, as we shall see -- but is also a totally unnecessary hassle. You should just use the stock
arm-gnueabi cross compiler that most distros package. It's no good for the ARMv6 models but it is intended for v7+.
I have a Fedora 23 card I use in the Pi 2 and 3 with
omxplayer installed. I didn't compile it at all however (I may have tried, I don't recall), I just used the Raspbian binary. I'll step through how you can do that. The explanation here is longer than
.configure; make; make install but the process is much shorter and less prone to unpredictable problems. Plus you may get to learn some tedious details about how binary executables are packaged and linked. >_>
I'll break this into steps since it is kind of convoluted.
- Download the
- Extract the
- Check the executable linkage (and install
- Install the omxplayer libs
- Install a couple of Debian armhf packages
- Install the Fedora libs
- Install the OMXPlayer executables
- Consider permissions on
1) Download the
First you have to download it; this will be in the form of a
.deb package, which is what the Raspbian package manager uses. Usually they can be found here, but not omxplayer -- I've never bothered to find out exactly how that system works to track down everything the repo offers via the package manager, but you can download them via
apt with a Raspbian system anyway.
In this case you don't even have to do that because a quick search reveals the OMXPlayer Builds page, and note if you check
apt show omxplayer on Raspbian, that appears to be exactly what's used there. Download the "Latest build" deb, e.g.:
The last command is optional and just to verify the integrity of the package. It should output a match to the "SHA1 Hash" shown on the download page.
2) Extract the
You should be working
su root for the rest of this, unless you want to just install this in a particular user's $HOME. If so you can extrapolate how yourself.
As explained on wikipedia, a deb file is an
ar file mostly wrapping a couple of tar archives. Tools for unpacking them are standard on any GNU/Linux system, including Fedora.
ar x omxplayer_0.3.7~git20160713~66f9076_armhf.deb
You might want to do this in a temporary empty directory because it doesn't create one, and extracts a few different files. The one we are interested in is
data.tar.xz. This will unfold into a directory tree -- one which parallels the root filesystem, although in this case it only includes stuff for the
tar -xJf data.tar.xz
You probably want everything that's there, and it's up to you whether you place it in
/usr/local, which is structured the same way and will work. To do the former, you can just copy
/ and (un)tar it there -- rather than then creating a
/usr tree, it will all get extracted into the existing one (in this case I recommend first doing it in the temp directory, because there's some stuff we have to check, and this makes it easier to find).
Here's what the tree in that particular tarchive actually includes:
│ ├── omxplayer
│ └── omxplayer.bin
│ └── omxplayer
│ ├── libavcodec.so -> libavcodec.so.57.48.101
│ ├── libavcodec.so.57 -> libavcodec.so.57.48.101
│ ├── libavcodec.so.57.48.101
│ ├── libavdevice.so -> libavdevice.so.57.0.101
│ ├── libavdevice.so.57 -> libavdevice.so.57.0.101
│ ├── libavdevice.so.57.0.101
│ ├── libavfilter.so -> libavfilter.so.6.47.100
│ ├── libavfilter.so.6 -> libavfilter.so.6.47.100
│ ├── libavfilter.so.6.47.100
│ ├── libavformat.so -> libavformat.so.57.41.100
│ ├── libavformat.so.57 -> libavformat.so.57.41.100
│ ├── libavformat.so.57.41.100
│ ├── libavutil.so -> libavutil.so.55.28.100
│ ├── libavutil.so.55 -> libavutil.so.55.28.100
│ ├── libavutil.so.55.28.100
│ ├── libswresample.so -> libswresample.so.2.1.100
│ ├── libswresample.so.2 -> libswresample.so.2.1.100
│ ├── libswresample.so.2.1.100
│ ├── libswscale.so -> libswscale.so.4.1.100
│ ├── libswscale.so.4 -> libswscale.so.4.1.100
│ └── libswscale.so.4.1.100
│ └── omxplayer
│ ├── COPYING
│ └── README
8 directories, 26 files
That's output from
tree, BTW (
dnf install tree on Fedora). The
-> indicate some of the files have local symlinks, which is normal for shared libraries. And this is pretty nice: OMXPlayer, true to being a video player created for the pi, includes all those libraries.
3) Check the executable linkage (and install
That doesn't mean it's guaranteed to work out-of-the-box this way on Fedora ARM. We want to start with the stuff in the
The first one is a shell script wrapper on the second one. The second one is the actual executable and links to more shared libraries than it comes with, which is also very normal. We need to check that all they are all available.
There's 40 lines of output. A lot of them will be "=> not found" and that's the stuff we need to figure out.
omxplayer using hardware acceleration is the presence of the (propretary?) libs included in
/opt/vc/lib with Raspbian. If you don't have that stuff on your Fedora system, you should (it may or may not help w/
mplayer, BTW). I have an explanation of how to do that at the bottom here under
/opt/vc. If you're using some spin that was intended for the pi you probably already have it. Check.
Since I've already done that, I can verify that this version of omxplayer links to those GPU libs:
> ldd omxplayer.bin | grep /opt/vc/lib
libWFC.so => /opt/vc/lib/libWFC.so (0x76f0d000)
libGLESv2.so => /opt/vc/lib/libGLESv2.so (0x76ee8000)
libEGL.so => /opt/vc/lib/libEGL.so (0x76eaf000)
libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76e88000)
libopenmaxil.so => /opt/vc/lib/libopenmaxil.so (0x76e72000)
libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76d9e000)
libvcos.so => /opt/vc/lib/libvcos.so (0x76d84000)
libbrcmGLESv2.so => /opt/vc/lib/libbrcmGLESv2.so (0x7690e000)
libbrcmEGL.so => /opt/vc/lib/libbrcmEGL.so (0x768d4000)
This all has to work out first. Don't bother with the rest until you get to this point (all the
/opt/vc/lib links above exist).
4) Install the omxplayer libs
Once that's done, install all the libs that came with
omxplayer. Since they're in a particular directory inside the tree unpacked from
data.tar.xz, just move it:
mv usr/lib/omxplayer /usr/lib
Now create a file
/etc/ld.so.conf.d/omxplayer.conf with two lines:
(Note the second of these doesn't exist yet.) Run
ldconfig, then check the output of
ldd omxplayer.bin again.
5) Install a couple of Debian armhf packages
There will be some
=> not founds left. To home in on them:
ldd omxplayer.bin | grep "not found"
Most of these can be installed from Fedora, but there are a few I notice I've installed from other Debian packages, possibly because they aren't found in Fedora repos for one reason or another. We'll tackle those first:
I used Debian armhf (ARMv7) packages for these, and this is why I created the
/usr/local/lib/arm-linux-gnueabihf directory. The packages can be found here:
They both can be opened with
ar x and will contain a
data.tar.xz that can then be opened with
tar -xJd data.tar.xz -- this time definitely do it in a new temporary directory or things will get a little confusing.
The first one, libpcre3, will contain a number of things you can ignore. There are two "arm-linux-gnueabihf" directories in the tree from the tarchive, one in
lib and one in
usr/lib. Each contains a pair of files, one of which is a symlink to the other. Copy all four files into
/usr/local/lib/arm-linux-gnueabihf. Remember, you should be working as root at this point or otherwise making sure the ownerships are root.
The other one, libssl1, contains again mostly stuff you can ignore (note I probably have not used whatever functionality
omxplayer requires from this, which is probably related to streaming from HTTPS sources -- however, all the linkage at least works out and there are no failures due to missing symbols, which would be a fatal problem). In the
usr/lib directory of the unpacked
data.tar.xz there will be a directory and two files:
The first one is a directory with various shared object files; I don't actually think any of it comes into play (I believe it has to do with a Debian oddity regarding the use of openssl, so shouldn't affect other Fedora software either). However, it's small so copy those three things into
There are actually 4 libs there, so one more than the
omxplayer.bin linkage needs, but that's fine. However, for whatever reason when extracted as above from the
.debs they are not executable, which they need to be, so for each one:
chmod 755 libcrypto.so.1.0.0
chmod 755 libpcreposix.so.3.13.1
chmod 755 libpcre.so.3.13.1
chmod 755 libssl.so.1.0.0
and when you're done, run
If that line was included earlier in the
/etc/ld.so.conf.d/omxplayer.conf and you've done all this properly, those three needed links from
ldd omxplayer.bin should now be found. You can check the
.so with ldd, i.e.:
> ldd /usr/local/lib/arm-linux-gnueabihf/* | grep "not found"
ldd: ./openssl-1.0.0: not regular file
That's the only line of output you should get from that.
6) Install the Fedora libs
For each of the remaining "not found" libraries you're going to have to find the appropriate Fedora package, e.g.:
dnf provides "*/libgnutls.so.30"
Notice the glob pattern with the prefixed "*/". Probably most of these are in a
lib directory but they may also be in their own subdirectory so that's what works. Then:
dnf install gnutls-3.4.14-1
After each one, check
ldd ... grep "not found" again because some of them may get covered together.
7) Install the OMXPlayer executables
Make sure all the "not founds" are resolved at this point. The from the omxplayer .deb's unpacked
data.tar.xz, install the
omxplayer binary and wrapper,
cp -a usr/bin/* /usr/bin
and for the man page, etc.
cp -a usr/share/* /usr/share
8) Consider permissions on
Finally, if you want to use
omxplayer as a non-root user, you'll need to grant read/write permissions to
/dev/vchiq. You can do that various ways; the easiest is (as root or via
sudo if possible),
chmod a+x /dev/vchiq. This won't persist across reboots but you can put it in
/etc/rc.local on Fedora 23 ARM (if it exists; Fedora has moved away from this practice but it's there on mine -- if it isn't leave a comment). Otherwise you'll get:
failed to open vchiq instance
There are more nuanced ways to do this, such as creating a group, setting permissions just for that group, adding the user to that group, and setting up a udev rule instead of using
rc.local, but I've never bothered.
Since I actually had the previous version (0.3.6) installed, I went through this with the 0.3.7 package to confirm it works, using a couple of
.mkv test files from here. The 55 Mbps clip with audio recommended at the bottom as a equivalent to Blu-ray played fullscreen no problems with sound (which I am positive the sounds are not made by jellyfish...), albeit right now that card is in a Pi 3, it shouldn't matter much. Beware omxplayer won't play all .mkv files, just H.264 ones, so if you use those as a test tick that box at the top so you don't waste time downloading the wrong thing.
If you have HD .mkv files that aren't H.264 too bad -- the Pi's hardware won't help with them and it will suck ("Your system is too SLOW to play this!"). There may be tools around to convert them. I believe YouTube is H.264 based (I've used
yt-dl with the Pi).
Good luck. If this looks bewildering, just work through it slowly a step at a time, it is all there, pay attention and read carefully. If you have a problem leave a comment.