For distributing on OSX, I use dynamic linking and manually create an OSX bundle. Then, I copy over all the necessary dylibs using https://github.com/auriamg/macdylibbundler (be mindful of the issue here https://github.com/auriamg/macdylibbundler/issues/22).

For cross-compiling, you can use the mingw64 cross-compiler, I know people have had success with it.

For Linux I am not very familiar with how to get that working... I typically just static link Allegro and call it a day, but you probably can do something like what is done in OSX and distribute the necessary shared libraries.

Now as for the details... I can only be of help with the OSX process since I do it regularly (for Windows I have access to a Windows OS, and compile things there). I'll try to write up a tutorial.

Hey Edgar, here's a bit more info about what you experienced with my game:

1. The ship is supposed to flash for around 5 seconds after you spawn, to signify temporary invincibility to asteroids, so you don't get spawn-killed by an asteroid that moves so fast to the spawn that you don't get a chance to move or shoot it. It's not supposed to flash for much longer than that, though.

2. I don't know why it crashes when you fire the laser. I downloaded my Github version and compiled it using my script, and it works fine. Make sure the following 3 sound files exist in the same directory as the executable:

   • laser.wav

   • thrust.wav

   • explosion.ogg

   Did you test any of the other sound effects? To trigger thrust.wav, push the up arrow key to fly your ship forward. To trigger explosion.ogg, you either shoot an asteroid with a laser (which isn't possible if the game crashes when it can't find the laser sound effect), or fly your ship into an asteroid to blow it up after your invincibility period is over. Maybe we'll get more insight into this problem if we check whether the other sounds work.

3. As for the malformed link in my original post, I don't see an edit button for my post. Sorry.

SiegeLord, I have tried doing a static build before but it never works. I was able to build a static library of Allegro just fine, but whenever I try to use it and compile a static version, I get a billion errors and I don't know what a single one of them means.
Here's the command I use to do static compilations:

gcc -static src/main.c -lm -lallegro-static -lallegro_primitives-static -lallegro_main-static -lallegro_audio-static -lallegro_acodec-static -lallegro_font-static -lallegro_ttf-static -oStaticAsteroids

The error message is so big and long that I can't put it here. I put it on pastebin instead. Click here to see the hell error message at your own risk.. I'm surprised Pastebin even allows me to host a paste that huge.

I've tried doing a "Monolithic build" where I distribute a monolithic library with the program, but it never works. It builds fine, but whenever I run the program, it complains it can't find the library, even though it's still there, and I directed GCC to compile with the one in that directory, and link to the one in that directory.

I don't even think I'm going to compile for Windows just yet. Compiling a portable build for Linux has proven to be a hell nightmare for me, and it's supposed to be the easiest. I think I will get a working Linux build going and only then will I transition to Windows.

Thanks for all your help so far, guys. Hopefully I'll get a build working for everyone eventually.

I think that to get shared libraries working on other Linux systems you need to distribute all dependencies, including the C runtime itself. That's because of compatibility issues between different versions of GCC, etc. If you try to run the binaries that you built on your system without providing everything then they'll likely get linking errors or crashes when they execute your game as a result of a runtime incompatibility.

ldd(1) should list the dynamic link dependencies for an executable or library. In theory, you could script up a program to recursively follow them all the way back, and copy the appropriate files into a folder to tarball up. For example, here's the output for my core Allegro 5 shared object:

	linux-vdso.so.1 =>  (0x00007fffb2b87000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f177cca5000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f177ca88000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f177c74e000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f177c544000)
	libXpm.so.4 => /usr/lib/x86_64-linux-gnu/libXpm.so.4 (0x00007f177c332000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f177c122000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f177bf1f000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f177bd14000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f177ba9f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f177b6d5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f177d2ae000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f177b4ad000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f177b2a9000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f177b09f000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f177ae99000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f177ac87000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f177aa6d000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f177a844000)
	libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f177a640000)
	libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f177a43d000)
	libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f177a236000)
	libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f177a033000)
	libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f1779e02000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f1779bff000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f17799fd000)
	libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f17797e2000)
	libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f17795dd000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f17793d7000)
	libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f17791c6000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1778fc2000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1778dbc000)

You will likely need to write a shell script launcher that sets some environment variables so that when the user executes what they think is your game, it sets up an environment that loads libraries from your subdirectory, and then executes your game using the new environment.

The LD_LIBRARY_PATH variable should instruct the runtime loader to search that path for libraries. I'm not sure if that works for the C runtime itself, but I don't see why it wouldn't. I've just never attempted this before. For example:

On Linux itself, I've found that (perhaps unfortunately) the most surefire way of doing this is to just build traditional packages - that is, RPM or DEB packages - for your game.

You'd build a dynamically linked binary per target Linux, add each to a package, specify a dependency for Allegro in those packages (eg. liballegro5.2 on Ubuntu), then distribute them.

A better (and newer) way might be to use Snaps, which apparently make building easy across Linuxes. Haven't tried these yet though. Might be a good idea to add a section to the Wiki a la "how to package and distribute your game".

Edgar,
I use .h headers for just about every C file inside src/, and I can't see anywhere where I included a .c file directly. The only C file that does not have a corresponding header is main.c. I will admit that I probably don't do enough with the header files. Most of the time, I use them for the sole purpose of having a safe and easy way of making sure I only include a file once. I'm pretty new to C, coming from other languages, and this was my first full project.

As for the audio thing, it worked fine on my machine and many other linux machines before. I went ahead and implemented your suggested change and recompiled, and it still works fine on my machine, so I implemented it into the Github repo. I'm surprised I've never had a problem with it before; I did compile this program on a few different Linux installations, and I've never had a problem with the sound before. I was kind of working on a deadline with this code (I wrote it for an assignment in AP computer science at my highschool), and I think I got the information for those functions from the Allegro 5 documentation. I must have misinterpreted it. Thanks for catching that for me.

When you say the rotation is off, what exactly do you mean? Here's a couple pointers about how rotation should work inside of my game:

1. The ship is supposed to rotate around its but, not around the center.

2. The ship should fly straight where it's pointed and fire lasers straight where it's pointed.

As long as those two things are happening, I'm happy with it. I wrote the game so the ship would rotate around its but because you can use it to dodge asteroids in a slick and kind of funny way.

As for pkg-config, I haven't used it in a little while and I probably don't know the full extent of its power. I'll look for a good guide to it and try to get a static build going with it.

dthompson, snaps look really interesting. I think I will learn to use those, alongside learning to make regular packages, too.

Thanks everyone for all your support so far.

if (!al_init() || 
    !al_init_image_addon() || 
    !al_init_primitives_addon() || 
    !al_install_keyboard() || 
    !al_install_mouse() )
{
   return 1;
}

This is pretty poor advice if you ask me. Either these things "cannot" fail in which case there's no point checking, or they can fail, and if they do fail, the user will have no way of knowing what failed, and no way of diagnosing it.

It's also a good habit to get into cleaning up after himself, even though Allegro tries to do this automatically. Technically the kernel will also do a good job of cleaning up after him. You should still try to do it as well.

There's nothing "nuts" about that init code. The only thing that can be criticized there is the ever growing "failure" code. Since he has variables to track which things failed already he could condense that down into a single cleanup section at the end of the function using goto (or, for purely religious reasons, write it in a separate function).

This has two advantages: it's less repetative and less code, and it's more reliable. Every time you add an initialization you only have to clean it up once instead of many times, of which you are likely to miss some (as did the OP).

The only disadvantage is the use of goto, which many will frown upon, but in this usage style is perfectly reasonable. Again, this could be moved into a function instead. That could save on the many fprintf calls too (have one inside the function operating on parameters). The downside would be having to pass so many parameters (unless they're global, but that's a whole new can of worms).

There's no way for a noob to expect the platforms to differ. Allegro is supposed to be cross-platform so this should have worked the same in Windows. The memory leak was still a bug, but he's right to be confused by it.

I use a pattern like this for initialisation:

Because of the large number of assertions you'll need to make during your init phase, it's good to use a helper function (must_init in my case) to DRY up the code, making it more readable and easier to change.

As for your shutdown phase, al_uninstall_system is normally called implicitly when your program exits. This takes care of shutting down all of Allegro's subsystems, but there may be some things that you want to explicitly destroy (like filehandles) before the OS tosses away your heap.

If you built Allegro without audio support then everything will succeed until you try al_init_audio_addon(). Since Allegro's build system fails gracefully for things missing like that by default most users will not even realize they didn't build audio support and will not understand why the game is crashing. If your program just exits or gives a useless Windows-style "something failed" message then they have no idea what failed. Now they have to pull out a debugger because you were too lazy to tell them what failed, and they might be too inexperienced to even know how to do that. They might not even be programmers. They might just be gamers.

typedef bool (*BOOLFUNC)();
typedef struct { BOOLFUNC func; char msg[255]; } INSTALLER;
#define INSTALLER_ELEMENT(func) { func, #func }
INSTALLER installers[] = {
    INSTALLER_ELEMENT(al_init),
    INSTALLER_ELEMENT(al_init_image_addon),
    INSTALLER_ELEMENT(al_init_primitives_addon),
    INSTALLER_ELEMENT(al_init_font_addon),
    INSTALLER_ELEMENT(al_init_ttf_addon),
    INSTALLER_ELEMENT(al_init_acodec_addon),
    INSTALLER_ELEMENT(al_install_audio),
    INSTALLER_ELEMENT(al_install_keyboard),
    INSTALLER_ELEMENT(al_install_mouse)
};

This is good advice. I support this design, but didn't want to suggest it to the OP because it's a bit overkill for such a simple one-time routine that's only ever going to get so complex. Especially for a beginner. What the OP has done is perfectly acceptable.

Fair enough, but the point stands.

We aim to please.

Yep, I'll agree with that further to this, I'm glad that they're not prematurely optimising. Copy+paste is all well and good until a) you're nearing production or b) the code starts dancing about in front of your eyes.

Get some glasses.

I use this in my library - EAGLE_ASSERT : https://github.com/EdgarReynaldo/EagleGUI/blob/master/include/Eagle/Exception.hpp

All I have to do is :

   Allegro5System* sys = GetAllegro5System();
   EAGLE_ASSERT(sys);
   if (sys->Init(EAGLE_FULL_SETUP) != EAGLE_FULL_SETUP)) {
      return -1;
   }

And then EVERYTHING is ready. And all failures are automatically logged. EAGLE_ASSERT gives the expression, line, function and source file it came from.