I've managed to track down all of Allegro's dependencies and built it on Windows, but it seems I can't link against it with the latest OpenAL (1.16), I get a symbol conflict during linking:

openal-soft-1.16-static.lib(helpers.obj) : error LNK2005: _al_fopen already defined in allegro-5.1.9-static.lib(file.obj)

Apparently OpenAL has a function named al_fopen, which conflicts with Allegro's same-named function and thus it won't link. I can of course use 1.15, which doesn't have this issue, but it's something for anyone building Allegro themselves to keep in mind.

OpenALSoft's al_fopen doesn't look like a public function... there seems to be some sort of... miscompilation error. Either way, it probably won't happen if you use a DLL for OpenAL (or Allegro).

Yeah, I'm trying to keep my entire engine self-contained in a single ~2MB executable, which I have managed to do up to now. Static linking is always a pain, but it's a necessary evil for this project.

That said, I was able to successfully link the library using OpenALSoft v1.15.1, which doesn't have the al_fopen function. From what I can gather, while its not an external function, it is nonetheless extern because it's used outside of the source file it's defined in, causing the symbol conflict when attempting to link it statically with Allegro.

Out of curiosity, what would I be losing if I built Allegro without OpenAL support? Is it a required dependency or...?

Yeah, looks like it's a normal, unfortunate behavior. Under Linux, you can rename the symbol using objcopy --redefine-sym al_fopen=openal_al_fopen openal-soft-1.16-static.a. I think you can do something like that in Windows too using the lib tool, but I've never tried it.

It's entirely optional everywhere, I believe (certainly so on Windows). Allegro doesn't use it's more advanced features, so you're losing nothing.