fallenguru wrote: ↑Thu Mar 31, 2016 12:25 pm
It's possible now, from memory:
1) oss part
Call configure with --prefix=$HOME.
Comment out the call to ldconfig in the Makefile (it would require root).
Yeah, I really wish the makemkv devs would remove that, or make it conditional on having UID 0 when 'make install' is run. Despite the assertions in their code, it's NOT at all necessary to install makemkv as root.
(I also wish they'd install the shared libraries with the executable bit set, as is standard practice for ELF binary objects.)
fallenguru wrote: ↑Thu Mar 31, 2016 12:25 pm
$ make
$ make install
$ export LD_LIBRARY_PATH="$HOME/lib:$LD_LIBRARY_PATH"
That last part isn't even really necessary, if you build with system dependencies for the shared libraries. Because, it turns out they don't depend on
each other at all. Nor does the makemkv executable depend on any of the shared libraries built from makemkv-oss. The only thing that
does depend on libmakemkv.so.1 and libdriveio.so.0 is makemkvcon.
Sooo...
fallenguru wrote: ↑Thu Mar 31, 2016 12:25 pm
2) closed part
Edit the Makefile to say PREFIX=$HOME instead of PREFIX=/usr (it's close to the top).
$ make
$ make install
Makefile variables can be overridden by commandline args, so easier than editing is to just run:
Code: Select all
make PREFIX=$HOME
make install PREFIX=$HOME
Now, with makemkvcon installed in $HOME/bin and the libs presumably installed in $HOME/lib, without setting LD_LIBRARY_PATH makemkvcon has no way of locating the libs.
RUNPATH to the rescue. Using the patchelf utility, we can add an after-the-fact RUNPATH to the pre-compiled makemkvcon binary so it'll be able to find the libs.
Code: Select all
patchelf --add-rpath '$ORIGIN/../lib' $HOME/bin/makemkvcon
et voila:
Code: Select all
$ ldd $HOME/bin/makemkvcon |grep home
libmakemkv.so.1 => $HOME/bin/../lib/libmakemkv.so.1 (0x00007f43124f6000)
libdriveio.so.0 => $HOME/bin/../lib/libdriveio.so.0 (0x00007f43124ec000)
This
won't work if any of the dependency libraries (like ffmpeg's libavcodec or libavutil — required by libmakemkv.so.1 — or makemkv's libQt5*.so.5 dependencies) are installed in non-system locations outside of ldconfig's control. Although, if they
are, it should still be solvable by patching a RUNPATH into either libmakemkv.so.1 or makemkv the same way.
For libmakemkv.so.1, if its other dependencies are in the
same library directory, you can just tell it to look there:
Code: Select all
patchelf --add-rpath '$ORIGIN' $HOME/lib/libmakemkv.so.1
With makemkv, you'd want to use the same RUNPATH we originally used for makemkvcon, above — assuming the libraries it needs to access are also in $HOME/lib. If you have Qt in some downloadable-install location like $HOME/Qt/5.15.2, you'd want this:
Code: Select all
patchelf --add-rpath '$ORIGIN/../Qt/5.15.2/gcc_64/lib' $HOME/bin/makemkv
If your distro doesn't automatically put $HOME/bin on your PATH when it exists, then... well, bad distro! no cookie. But you could also try using "$HOME/.local" as your --prefix argument and PREFIX= value, instead. $HOME/.local/bin is the new $HOME/bin, and these days is more likely to automatically show up in the $PATH.
The location of the files to modify would change, in that case, but the patchelf --add-rpath arguments DON'T change. That's the advantage of using $ORIGIN-relative RUNPATHs. (The exception is the Qt relative path, which would have to back out a level farther. So that one would become '$ORIGIN/../../Qt/5.15.2/gcc_64/lib'.)
Someone mentioned theoretical permissions issues getting access to hardware, as a reason to need a root install... but that's unlikely to be an issue.
For starters, it assumes the user even
wants to access any hardware drives. (I use makemkv entirely with disc images, no physical hardware is ever harmed or even involved in the making of my mkvs.)
Even for users who DO want to access hardware, udev and session-based permissions management on modern Linux distros should give the logged-in user ownership of any optical drive devices on the system for the duration of their session, so permissions
shouldn't be a problem for users directly signed in to a local desktop session.
And even if there
are permissions issues, it'd require
running makemkv as root to overcome them — having the binaries and/or libraries
installed as root doesn't make a damn bit of difference.
(Unless they have the setuid bit, which they should DEFINITELY not. Because that would be a massive security exposure. Run makemkv under sudo if you absolutely must, in order to access hardware devices, but do NOT grant it blanket, unsupervised root access. Unless you ENJOY getting pwned, I guess? Some people have weird kinks.)