fork of updated to not not work
Go to file
Lynne Megido fdce5f13a2
dejavu / i have listed this dep before / i need way more sleep / but late nights are the life i know
2020-04-09 02:54:13 +10:00
appimage use latest appimage version 2020-04-09 02:18:46 +10:00
docker dejavu / i have listed this dep before / i need way more sleep / but late nights are the life i know 2020-04-09 02:54:13 +10:00
flatpak Don't fail the flatpak build if the export directory doesn't already exist 2017-10-31 09:27:54 +01:00
snap Do full path replacements for executable and icon in desktop file 2017-09-07 15:22:55 +02:00
tarball remove unnecessary dependencies from dockerfiles, download license if not present 2020-04-09 02:03:45 +10:00
.gitignore more files to ignore 2020-04-09 02:37:12 +10:00
Getting added some notes to the 'getting started' section 2020-04-09 02:18:36 +10:00
LICENSE updated readme to reflect new repo, added license, moved hgignore to gitignore 2020-04-08 23:47:28 +10:00 updated readme and enabled flatpak builds 2020-04-09 02:36:34 +10:00


This is a fork!

This project was forked from the original BitBucket repo, which hasn't been updated in some time. Currently, the Docker image provided by that repo fails to build, as the Mercurial version that it tries to use dies when connecting to because it can't complete the SSLv3 handshake (which is a good thing). I've fixed this by updating the Dockerfile to use Debian OldStable instead of Debian Jessie. As of the time of writing, Debian OldStable is Debian Stretch. Debian Stretch was originally released 3 years ago, and uses Linux kernel version 4.9, meaning that any Löve binaries created should be compatible with any Linux system that was updated within the last 3 or so years.


The easiest way to use this project is with Docker.

# clone the repo
git clone
# run the docker image
REPO_PATH=love-linux-builder # the path to the git repo you just cloned
TARGET_ARCH=x86_64 # the target architecture. one of: x86_64 (aka amd64), i686 (aka x86, i386), armv7l (raspberry pi)
LOVE_VERSION=11.3 # the löve version you want to use
docker run --rm -v $REPO_PATH:/build/love-linux-builder lynnesbian/love-linux-builder:$TARGET_ARCH $LOVE_VERSION

If you want to build your game's .love file in the resulting builds, include in the root of the repo. There's also some other files you should include (, game.svg...) - you can learn about those files the Getting Started document.

A list of available löve versions can be found on the love2d wiki.


The original repo did not provide a license, meaning by default it is copyrighted by the author. I assume that the author did not intend this, and am releasing this fork under the MIT license. Please don't sue me!

The rest

The original README is as follows:

The script in this git repository can be used (on a sufficiently old linux system) to extract LÓVE binaries, and turn them into a portable build in various different formats.

This project is split up into multiple parts, and each part is responsible for a different build. Note that the tarball build is used as a base for the other builds.

See Getting Started for more information on how to use these scripts.


tarball contains a build script that extracts the love version currently installed on the system together with its dependencies to form a portable build. It also creates a small wrapper script that does the correct search path manipulations to be able to run the build.

Lastly, it contains the icon and a stubbed desktop file.


snap builds.. well, a snap. Instead of using fancy build tools that try to do everything for you, why not just do it manually?! Seriously though, you can still use snapcraft to build this, but at that point it just acts like a fancy mksquashfs, and an extra dependency at that.

NOTE: Due to nvidia driver issues I haven't been able to test these snaps yet. From what I can tell these issues have been fixed since the last time I tried. Let me know if you get them working so I can remove this note.


appimage builds AppImages, unsurprisingly. It uses binaries from AppImageKit, though you can build them yourself if you want to. And hey, this actually seems to work, too!


flatpak is used to build flatpak "packages". It requires the flatpak command line tool. Of course flatpak has some kind of repo system, so you can't easily distribute a flatpak file. Useful.


docker does not build docker images. Instead it builds a docker image so you can build portable packages yourself!

To build the container, you need to download the relevant SDL2 and LuaJIT source packages (and possibly update the references in the Dockerfile).

To use the container, run it as an application, mounting this repo as /build/love-linux-builder. You can optionally mount love source at /build/love, and if no source is provided it clones the repo and checks out the specified version. Note that the container requires exactly one argument: the version. This can be an arbitrary string, but for cloning to work it needs to be a tag, branch or commit.