Nearly a year after my rant about Handbrake’s switch from GTK+2 to a bleeding edge version of GTK+3, I am about to give up on my attempts to build the required GTK+3 static libraries into the handbrake package. Unlike the situation with applications that use Qt or WxWidgets for their GUI, creating a private run-time for GTK is like wading through the pools of hell. GTK wants caches, configuration files and stuff all over the place. My handbrake with private GTK+3 crashes because it might still be trying to use the older GTK+3 libraries on my Slackware 14.1 computer.
So I said to myself: “fuck it” and build Handbrake 0.10.2 for Slackware-current exclusively. The development version of Slackware does have a GTK+3 which is contemporary enough and with some tweaks, I was able to compile a (hopefully) working handbrake GUI.
It is of course possible to compile the commandline version of Handbrake on Slackware 14.1 because that does not require GTK+3 as a dependency. Come to think of it, perhaps I should adapt the handbrake.SlackBuild with a switch parameter that will allow you to skip the “ghb” GUI program and only compile “HandBrakeCLI“.
I wonder if anyone will step up and write a Qt-based wrapper about the HandBrakeCLI program. That would be really welcome, because I do not think that the Handbrake developers will ever produce a Qt based GUI variant. They attempted that once if I remember correctly, but nothing good came from that.
When I have some spare time I will prod further at getting Handbrake to use a private GTK+3 run-time, but don’t hold your breath. I have a program that compiled with zero errors, but it crashes on the GTK component libraries. I am not sure if I ever find out how to overcome that… I am not aware of anyone else ever successfully creating a GTK+3 based GUI program on Linux that used its own private library versions.
Anyway, have fun with handbrake if you are running Slackware-current.
You can get the package from my “restricted” repository. The package contains software which is under patent dispute (the MP3 and AAC audio encoders) so I can not host the package on the Slackware server.
Thanks Eric! I had been using Handbrake-0.9.9, although not for a long while.
I uploaded an adapted handbrake.SlackBuild script which can compile just the commandline program. This way you can use it on Slackware 14.1.
# WITH_GUI=NO ./handbrake.SlackBuild
Just a note, this package requires
to be installed,
Well p431i7o – I did mention that this package was built for slackware-current, and “at-spi2-atk-2.16.0” is part of slackware-current. I always expect a full installation of slackware-current for my packages.
I’m no stranger to compiling things, but handbrake is a cast-iron pain in the ass. It seems like that’s the trend in a lot of programs lately. Consequence of people not installing things from source anymore? (Dating myself, but when I started with Linux, that’s how you installed programs.)
Jen, I think that the main issue is that most software is no longer tested ubiquitously. If their software compiles and runs on Ubuntu and Fedora, that is where most developers probably stop caring.
Most other distros patch the hell out of their packages to overcome all sorts of quirks, and that often results in software that is “made” to compile correctly on those distros by adapting the code until it works… and then our vanilla Slackware program code will cause a compilation to fail.
And indeed this is something I see more often these days. I’ve spend an awful lot of time on this handbrake package. But there’s also the new ffmpeg 2.8 which is sitting on my server in source format, and I can not get it to compile without errors. That has been bugging me for over a week. VLC is another example where the developers are not looking further than Ubuntu and MS Windows, and I have a lot of frustration to cut through every time there’s a new source release.
I have no time to even use the packages I compile, except perhaps that I can work in my own Plasma 5 desktop session, listening to music played by VLC…
But still, the ubuntufication of the software landscape is a creeping disease, less controversial than Redhat’s systemd perhaps but dangerous to the niche distros nevertheless. The time required to keep all the nice software for Slackware up-to-date is expanding and there will come a point at which I have to come to the conclusion that I can no longer fit these Slackware activities in my private life anymore. I really fear that moment, but it appears to be unavoidable. I just hope that it will be years away.
Yeah…it is a problem. While it’s nice that Ubuntu brings people to Linux who might not otherwise, it’s also a bigger problem for Linux, as a whole. Granted, all things change, but not all change is good.
It also seems like the Linux community is less inclined to DIY-type fixes. Hell, I’ve had people yell at me that compiling WINE from source would harm my system. I don’t know what the hell they’re doing or how their distros are set up, but that’s why /usr/local exists… I know. Preaching at the choir. 🙂
You read my mind! I was just going over the updates to current over the past few months and noticed the GTK+3. I immediately started to wonder if you’d put out a new handbrake package. Like magic, a few days later, here we are.
As to the growing headaches caused by trying to compile modern programs from source, I totally agree with all the previous comments. Up until i switched to -current about a year ago, I always compiled 99% of all my non-Slackware released software. Unfortunately, these days I just don’t have the time needed to keep up with all the updates, let alone trying to fix build issues. I still use slackbuild scripts whenever possible, but now I usually check your repositories first.
Thanks for everything you do for the community.
I feel your pain, Eric. I remember a discussion thread in the Salix forum a couple years ago, where George Vlahavas stated that “VLC probably runs perfectly on the VLC developer’s PC”.
When I choose a piece of software, be it an application, a desktop environment, a distribution, whatever, I try to always take into account some sort of perennity factor. Or stated differently, if I see that a software project is starting to get insane, I don’t hesitate to jump ship and move on to something that does the job equally well, without making me jump through burning loops. Remember back in 2005 (if my memory serves me right) when Patrick decided to just dump GNOME? I think that was a very sane reaction. Not that I particularly disliked GNOME (in fact, I’ve been a heavy GNOME user for many years). But I perfectly understood Patrick’s motivation to dump it when the project became more and more unmaintainable. As far as HandBrake is concerned, I’d give up on the app and concentrate on learning to handle video encoding with mencoder or transcode, two very powerful tools. Many years ago, I wrote a detailed article about ripping DVDs with mencoder, but unfortunately I don’t have it anymore. I’ll try to fish it out of my memory and write a HOWTO on the subject. Cheers, Niki