Have you ever compiled the source code of an open source application?
 

We recently asked if you've ever modified the source code of an open source application. This time we want to know: Have you ever compiled the source code of an open source application?

--jeremy

Yes, Audacity for one to get audio playback many years ago now. But while I can't remember what the exact issue was now, I had to compile it with a particular option enabled that wasn't enabled in the packaged version of it. I do remember it was openSUSE I was using at the time.

I've also compiled dvbcut, both the Qt3, 4 and 5 versions. In relation to the Qt3 version, while there are a couple of distros that have packages for that version of it; I found it better to compile and build it myself to get certain features that the packaged version of it was not built with - from memory I think that was video playback within dvbcut itself. I've not found any packaged version of it for the Qt4 version of it that I can remember, so I had no choice but to compile and build it myself. And as far as I know, the Qt5 version of it is only available on github, so again, no choice but to compile and build it myself. It's perfect for when you record DTV and it's recorded in MPEG TS, because dvbcut doesn't re-encode the file, and you can just save the parts of the video you actually want, then save it into MPEG PS to convert it to whatever other format you need.

As well as maybe a few other things that currently escape my memory.

I've also compiled my own code since I'm currently learning how to write my own software.

:redface:

No.

I had to recompile a note-taking app when I was performing updates, I didn't know what I was doing, but I entered the commands and poof-it worked again.

Long live the nerds that live online and help other nerds that need answers!! :)

Audacity is a right pain to compile.

Yes, I frequently do that if I want to install something that isn't in the repository. There are sites that provide distro-specific packages but I always feel safer when something is compiled directly against my local libraries.

When I was using really old hardware, I frequently built my own kernels. And of course I've done quite a few LFS/BLFS builds.

Like I said, it was many years ago now - although the packaged version of it I have now since I changed distros has problems just loading up (but I've been too lazy to try and fix it or build it again myself). But I haven't compiled it for a long time since I was using openSUSE many years ago. From what I remember (again, long time ago now), as long as you had all the deps installed it wasn't too bad. I just wish I could remember what the issue with the packaged version of it was, as well as exactly what build option it was that I needed, but for the life of me I cannot remember! I even tried doing a search before, but even that failed to jog my memory!

Yep - I've compiled everything from kernels to Seismic Unix and MakeMKV.

I recompiled a C program once, that hardcoded a mouse cursor into its source. I changed the graphics and recompiled it, though I've had more programs fail to compile than compile because I still don't understand the magic involved when it doesn't work.

I don't think there's a suitable guide for beginners-- you just do what it says, when it doesn't work you try a few other things that don't work, then you swear you'll never do it again. But maybe there's another way that doesn't involve 10 years of practice (and 15 years of patience.)

So many times it's supposed to "just work." And sometimes that's what happens.

If it doesn't "just work", that's the fault of the person who made the package.

Certainly.

https://github.com/ginggs/gelemental
https://www.dillo.org/download.html
http://www.gnu.org/software/units/units.html

To name a few.

But not with a make install. Compiled them into a package, so a package manager could install them and keep track of them with all dependencies. Even if they don't work when you're done, you can simply remove them. Also no conflicts with the already installed libraries.

Thanks to all the dev's that worked hard on, and maintain each distos package manager.

I blame the packager for Audacity :p

It took ages too since that was on either a Pentium 4 or a cut down P4 (Celeron) processor from memory - I think it was on the Celeron processor (don't remember exactly which one it was tho).

qmail, to apply John M. Simpson's patches.
clamav, before I discovered it was in the repositories (I was doing what the "Don't panic" message links to when the version changes).

I'm sure there were others over the years.

Emacs and UW imap mail application
 

Needed emacs on systems with no binary. Also needed to 64 bit to edit big file.

Wanted imap mail on a Sun workstation.