Full-standalone Linux binaries. Virtually possible?

[Ubermann]

Because windows is just zip the "compiled" .exe with the required dlls.

But when I "ldd <binary>" on my Linux, I obtain a large list of required libraries.

The problem with this is that I'm not sure which libs are common to every Linux and which not.
I am very interested on this because some people that doesn't know what LÖVE is they are likely not to install it for running the .loves or download and install all required libraries, so a full-standalone like in Wondow$ would be really nice.

Any tip?

Thanks.

[josefnpat]

I've done a ton of research on this, and the short answer is it's really hard to do right.

TLDR;
Your best bet is to distribute the .love for linux folks.

The love binary with it's current dependencies require that the OS uses a version of each library that isn't too old and a library that isn't too new, making for dependency hell. Between that and the multitude of linux distros, it makes it incredibly hard to have an end-all solution.

Basicer, on IRC, in an attempt to minimize the dependencies, cut out the jpeg library, but from what i understand it is prone to memory leaks. https://bitbucket.org/basicer/love-less-deps

He also found the oldest version of ubuntu that love 0.8.0 would run on (7.04 I believe) and built them from source on there, so that the dependencies would allow it to run on most versions of ubuntu.

You can find a few builds here; http://basicer.com/love-bins/

I also have some plans in the works for an end all solution, but it's on my todo list so to speak.

edit; it is also my opinion, if you hand a linux person a .love and they don't know how to make love (no pun intended), they probably shouldn't be running a variant of linux that doesn't have love in the repos (e.g. debian, ubuntu, arch, etc). I know it's kind of a dbag thing to say, but it's kind of the truth.

[Dattorz]

What we could really use is a system that checks for dependencies and then installs them from the distro's repositories using the package manager. I say this because most Humble Bundle games that broke for me on Linux could be fixed by removing the bundled libraries and just using the ones installed on the system.

So far this project looks quite promising, and I hope developers pick up on it at some point:
http://listaller.tenstral.net/

You create a distro-agnostic package file that includes all your files, and leave it up to the installer to check and fetch the dependencies.

Outside of that, devs will still need to compile a binary on some lowest common denominator distro (unless it's intended for enterprise distros, I wouldn't go for anything older than two years - Linux users are generally quite willing to update their OS). Of course, you might still run into problems with EG. an older libpng not being offered by the distro's repositories (say, you might need libpng12 but only libpng15 is offered). I think this is more of a distro problem and the distro packagers should be in charge of fixing this, as there is a growing need for including compatibility libraries now with the popularity of Humble Bundle.

Edit: If you need something right now and you don't mind using something a bit more old-fashioned and un-Linux-like you could try Nixstaller, which has been used for Humble Bundle before and works okay-ish:
http://nixstaller.sourceforge.net/

I wouldn't use an installer if you're just creating small games that you want to share with your friends or whatever. Having to go through a full-blown installation for that kind of thing will most likely just end up annoying users.

[Inny]

As a Linux user, I prefer the .love file. Though, I understand that if you want to distribute through Steam or something, it needs to be a proper binary. This may require you to modify the Love source code to change how it loads its link libraries. Since all of the libraries are MIT now (IANAL, double check that), you should be able to static link all of the requirements, and then cat the binary and your .love together for a distributable package.

[Boolsheet]

Not quite. LÖVE and its dependencies have the following licenses.

zlib licensed are: LÖVE, PhysicsFS, Box2D, zlib.
MIT licensed are: Lua, LuaSocket, UTF8-CPP.
BSD-style licensed are: libogg, libvorbis, FreeType (FreeType License), GLee.
libpng licensed is: libpng.
libjpeg licensed is: libjpeg.
LGPL licensed are: DevIL, OpenAL Soft, SDL, mpg123.
public domain are: libmodplug, LZMA SDK.

The issue of static linking LGPL libraries comes down to if linking without modification is considered a "modified work" of the LGPL library. It's always necessary to provide a way to rebuild the application with a modified version of the LGPL library, however (not a problem with open-source LÖVE).

[Inny]

Again, this isn't legal advice, because I'm not a lawyer. But the stipulations of the LGPL is that you make provisions for people to gain access to the source code of the libraries that you've used. If you had an otherwise unmodified version of the Love binary (with just the link libraries made static), and also provided the .love file and all of the licenses and links back to the Love and its libraries, so that anyone could build their own version of love and be able to play the game... I would think that it would satisfy anyone looking to enforce the LGPL. The dynamic-link nature of the LGPL was always about letting users mix and match the .so or .dll files so that the source code doesn't need to be provided. Given that Love's full source is available, static linking isn't an issue. Just more of a hassle for the programmers.

Though, it is an important reminder that just because you put the .love in the binary, that doesn't mean it's protected, because zip files don't have a header, they have a footer. I can rename any valid love game to be a .zip and open the archive to gain access to the resources inside. Like I said, I prefer having a .love, because it's easier for me as a Linux user to use given that I've already installed Love via the official release. Go with the .exe .app .love threesome for distribution and everything should work out just fine.

[T-Bone]

During the four years I've been using Linux as my main OS, I've learnt one thing: binaries hardly ever work. There's just too much that can go wrong.

If it's just a hobby project kind of game, then just distribute the .love. If it's a more serious project (for example you want to sell at Humble Bundle) then make a .deb that installs love from the reps and then creates a nice launcher for the .love file. If you're ambitious, you can make a similar rpm as well.

[jpnk]

as a linux user i prefer either .love or .deb/.rpm/whatever. chances that a binary downloaded from the web will run on your computer without problems are generally quite small.

has anyone here ever used https://build.opensuse.org/ ?

[socketubs]

Sorry for reviving this dead topic. But is Linux distribution in same state as previous posts ?
Cause I think, current state is nearly broken for Linux.

Creating .love is cool when you are in a devel process or to share with your friends, but if you want to sell your game, I don't think you can rely on this method. Because you just can't ask all linux users that have the chance to have ppa to add it, and install love. This is not very acceptable.
Creating .deb or .rpm packages don't allow you to have games with two differents love2d versions on the same system. This is problematic for a isolated distribution.

Is it possible to statically compile love2D (I have no very much compiling experience) ?
Is it possible to embed shared libs like Windows in a package ?

I have done a little hacky python script that retrieve via ldd libraries and create a launcher, https://gist.github.com/socketubs/de78d7d5eeebcdd7642f
It works on some distribution but I have no idea if it's a correct method.
You can follow some of this work here: https://github.com/MisterDA/love-release/issues/7