How to distribute executables with shared libraries?

[7h30n]

It's about time I ask this newbie question.

As some of you may know, I'm making a roguelike with SDL library and I am compiling it both on Linux and Windows.
What I have trouble with is providing the people with binary version for Linux that works by executing the binary and doesn't require from the user to find and install needed library dependencies.

On Windows I just put in SDL.dll files along with the binary and everything works by double clicking on the exe.
How can I get pretty much the same result on Linux?

Thanks for your help!

P.S. I've been looking on google but I can't find a straightforward answer... Should I put .so files with the binary and create a script for user that sets his LD_LIBRARY_PATH to target where provided .so files are or what?!

[TheCreator]

If the library is open-source (and I believe SDL is), you can just make it into one huge binary, altogether with your game. There's virtually no reason to distribute libraries as separate files unless you want more trouble .

[Robobot]

Just to clarify, if you compile a standalone binary, you still have to adhere to the SDL's license, which is the LGPL. This means your game has to be licensed under the LGPL or GPL. The LD_LIBRARY_PATH solution is much more hassle-free. Also most Linux users will probably be able to install SDL themselves, if they haven't already.

I can't believe I registered to post this, but I'm lurking for quite some time now. Hi, folks!

[XLambda]

Just to clarify, if you compile a standalone binary, you still have to adhere to the SDL's license, which is the LGPL. This means your game has to be licensed under the LGPL or GPL.

That's actually not entirely true. The GPL is a viral license, but the LGPL isn't. That is, if you modify an LGPL'd piece of code, you'll have to release the source under LGPL. If you link to an LGPL'd piece of code, you aren't forced to adhere to the LGPL, and in fact software linking to an LGPL'd piece of code can be closed-source and even commercial.

[Robobot]

That's actually not entirely true. The GPL is a viral license, but the LGPL isn't. That is, if you modify an LGPL'd piece of code, you'll have to release the source under LGPL. If you link to an LGPL'd piece of code, you aren't forced to adhere to the LGPL, and in fact software linking to an LGPL'd piece of code can be closed-source and even commercial.

Okay, I should have pointed that out more clearly. What I meant with "standalone binary" was what UglyTroll was referring to as "one huge binary", aka static linking. If you do that, your code has to be under the (L)GPL.
What you say is of course entirely correct for dynamic linking.

[Krice]

Release the game as source code for Linux and let them figure out the rest. It's how things work in Linux anyway.

[yam655]

Just to clarify, if you compile a standalone binary, you still have to adhere to the SDL's license, which is the LGPL. This means your game has to be licensed under the LGPL or GPL.

That's actually not entirely true. The GPL is a viral license, but the LGPL isn't. That is, if you modify an LGPL'd piece of code, you'll have to release the source under LGPL. If you link to an LGPL'd piece of code, you aren't forced to adhere to the LGPL, and in fact software linking to an LGPL'd piece of code can be closed-source and even commercial.

If it's the LGPL v3 (and not v2) the anti-TiVo-ization clause means that a person needs to be able to recompile the SDL and link it with your precompiled object files. I've seen products shipped this way before. It is far less pretty than a shell script and an external library.

Your source isn't free, but to exercise the freedom of the GPL, they need to be able to re-link it.

Cheers,
Steven Black

[yam655]

Which is to say:

First: I don't think this is needed at all. Tell a Linux person you need the SDL and it should be distributed by their distribution and they should be able to install it. This gets it on the system LD_LIBRARY_PATH and you don't need to do any work.

Secondly: Look in to "source code obfuscation." You can mask your source while still shipping it. It's useless to fork and is not open-source, but it allows folks to recompile it. You might need to ROT13 the resource files, considering the focus most people have these days on such things. Just remember: even crappy encryption (like ROT13) means a violation of the DMCA if someone shares the monster stats. You can get their site taken down if it is hosted in the US.

ADOM managed to be released as binary for Linux successfully. It is possible, but there are some idiosyncrasies. (You can be hit by memory debug techniques used by default on some distros.) ADOM didn't provide all used libraries, and I remember running ADOM only to find missing library complaints, checking the binary for the libraries it used and installing them. With the tools available for Linux users, such a task is straight-forward.

Cheers,
Steven Black

[7h30n]

Thanks a lot for everyone's input! I guess I'll just list the dependencies for the binary and let the user find and install them. Overall ratio is in favor of Windows binary downloads, so yeah...

Another newbie thing I'm concerned with is 32vs64bit. I have downloaded Brogue and it's binary is ELF 32bit while I'm compiling and using 64bit library. Obviously I can't run Brogue because it says my libSDL is in wrong ELF class...

[Robobot]

Another newbie thing I'm concerned with is 32vs64bit. I have downloaded Brogue and it's binary is ELF 32bit while I'm compiling and using 64bit library. Obviously I can't run Brogue because it says my libSDL is in wrong ELF class...

Most distributions allow you to install the 32bit libraries in addition to the 64bit ones. Your distribution's wiki probably has an article on how to do that.

[yam655]

Another newbie thing I'm concerned with is 32vs64bit. I have downloaded Brogue and it's binary is ELF 32bit while I'm compiling and using 64bit library. Obviously I can't run Brogue because it says my libSDL is in wrong ELF class...

Most distributions allow you to install the 32bit libraries in addition to the 64bit ones. Your distribution's wiki probably has an article on how to do that.

That depends on the CPU type. Most 64-bit processors can run 32-bit code -- with the proper 32-bit libraries installed.

Do a: uname -m

If it says: "x86_64" you can run 32-bit "x86" programs without much trouble -- unless your distribution is backwards and isn't supporting that feature. The "x86_64" machine type was, at one time, known as "amd64" as it is an instruction set that originated with AMD.

The Itanium-class of Intel processors are 64-bit but cannot run 32-bit x86 code. They'll return "ia64" for the machine. Most 64-bit home computers are not "ia64" machines.

If you're running on an Itanium machine then you need an "ia64" version of Brogue, and you'll need to cross-compile to create binaries that the rest of the world can use.

32-bit binary support is optional, and to use Brogue, you need to install a 32-bit version of libSDL. I would consult your distro's help forum if it does not seem self-evident from the package manager. (Otherwise, just recompile Brogue.)

Cheers,
Steven Black

[7h30n]

Yes thank you. That does work.
I presume in reverse situation, 64bit binary will need to be recompiled for 32bit distros.

[yam655]

Yes thank you. That does work.
I presume in reverse situation, 64bit binary will need to be recompiled for 32bit distros.

Yes, most definitely. That, at least, can be easily tested. Virtual machines are your friend. On a 64-bit host you can have a 32-bit virtual machine. (On a 32-bit machine you cannot have a 64-bit host.) Windows and Mac OS X users can also reasonably build/test for Linux using virtual machines.

For the folks witthout access to a virtual machine, I say: You can install Linux to a USB thumb drive, install additional packages (and remove some of the crap you don't need for focused development), and build/test your program. Since Linux is free, this is doable without needing a separate license or jumping through hoops to get the OS to not freak out whn the underlying hardware changes due to booting it up on a different machine.

Cheers,
Steven Black