Distributing Allegro 5 games

Distributing Allegro 5 games

AMCerasoli

Member #11,955

May 2010

When you're doing a static link you can't link to a dynamic link library (.DLL) but instead you have to use the ".lib" or ".a" files, which you can find in your "lib" folder, which is inside your Allegro 5 binaries folder.

I thought that with visual studio as Matthew said, you just have to put MT. I don't think you have to link to all those libraries that you put there djchallis.

I think that error means you're linking to two libraries that are almost the same... Like if you were linking to allegro5-static-mt, and allegro-static-md too.

Edgar Reynaldo

Major Reynaldo

May 2007

Link to allegro-5.0.4-monolith-static-mt.lib first, and then to the libraries listed above. The first 7 or so should have come with your A5 binary package. The rest are system libraries, and if you don't have them, then I think something is wrong with your compiler installation.

Go to your drive root and search for winmm.lib from there. It's got to be somewhere, or else MSVC is borked.

cd /d c:\
dir /s winmm.lib
dir /s *.lib

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

djchallis

Member #13,637

October 2011

My bad, I am using allegro-5.0.4-monolith-static-mt.lib.

Of the libraries that Edgar listed the ones beneath the top 7 were found by that search command. When I add them (and not the top 7) it doesn't seem to have any problems (apart from the LNK2001 errors still).

I can't find the top 7 libraries in C:\allegro\lib, which must be why the compiler said it couldn't find them when I copied that list straight in. But I do find variants on them. So instead of dumb.lib there's dumb-0.9.3-static-mt.lib and other variants. I added the appropriate ones to the list for both debug and release.

Now when I compile it's not complaining about any of those new libraries, but it's still giving me the same LNK2001 errors from when I first changed allegro-5.0.4-monolith-mt.lib to allegro-5.0.4-monolith-static-mt.lib. The errors look like this:

1>main.obj : error LNK2001: unresolved external symbol __imp__al_flip_display

There's one for every allegro function I use.

torhu

Member #2,727

September 2002

Look for a folder like C:\Program Files\Microsoft SDKs, that's where the Windows API stuff is.

EDIT: symbols starting with _imp are used when you're linking with a DLL. Did you #define ALLEGRO_STATICLINK before including any Allegro headers?

---
Smokin' Guns - spaghetti western FPS action

Edgar Reynaldo

Major Reynaldo

May 2007

djchallis said:

I can't find the top 7 libraries in C:\allegro\lib, which must be why the compiler said it couldn't find them when I copied that list straight in. But I do find variants on them.

My mistake, I gave you the list for self compiled libraries, not for the binaries that Michal Cichon distributes.

As for that linking error, if you're linking to allegro-5.0.4-monolith-static-mt.lib and you have ALLEGRO_STATICLINK defined properly then you shouldn't get any undefined references to allegro 5 functions. Check your project properties one more time and make sure ALLEGRO_STATICLINK is set correctly.

djchallis

Member #13,637

October 2011

I thought I'd done that by putting it in C/C++ -> Preprocessor -> Preprocessor Definitions as I was advised to earlier.
I added "#define ALLEGRO_STATICLINK" to the top of main.cpp before the Allegro headers and those errors went away, but I got this instead:

1>allegro-5.0.4-monolith-static-mt.lib(wsystem.obj) : error LNK2001: unresolved external symbol __imp__PathFindOnPathA@8

As a side question, if most of you recommend static linking and it's so complicated to set up in Visual Studio does that mean you all use Code::Blocks? (or is it actually easy in Visual Studio and I've just messed it all up?)
I was originally planning on using Code::Blocks but the Allegro 5 tutorial recommended I go with Visual Studio. It said somewhere that I'd be able to distribute updates with fewer file changes (though I can't find that written in tutorial anywhere now), but I now figure that's talking about Visual Studio doing dynamic linking.
Should I actually just be using Code::Blocks?
(I should note I'm using XP, because the Allegro 5 tutorial for setting up Code::Blocks specifies Vista).

EDIT: I'd only added ALLEGRO_STATICLINK to C/C++ -> Preprocessor -> Preprocessor Definitions in debug and was trying to compile the release version, my fault there.
I still get the same error though, so no change in my questions.

Edgar Reynaldo

Major Reynaldo

May 2007

djchallis said:

Well, it wasn't quite right if the errors went away when you added the #define to main.cpp.

djchallis said:

1>allegro-5.0.4-monolith-static-mt.lib(wsystem.obj) : error LNK2001: unresolved external symbol __imp__PathFindOnPathA@8

That is from shlwapi.lib. I need to add that one to my list. Just put it at the bottom. Order doesn't matter for MSVC. (How did I know? I used grep for windows [grep -r -E "PathFindOnPathA" .*.*].)

djchallis said:

If you plan on making updates to your executable, but not to the libraries you are using, then dynamic linking is probably preferable because then your users only have to update the main exe file (which is much smaller with dynamic linking).

I use Code::Blocks myself and it works just fine. MSVC is probably comparable. Use what you like best. I doubt it's all that different when you get down to it.

djchallis

Member #13,637

October 2011

That did the trick! It seems to be successfully static linked now.
Thank you for all the help, and bearing with my mistakes.

Now that's all said and done I'm still not entirely sure which method (or which IDE) I want to use. Static linking looks a lot neater without dlls everywhere, but the .exe file has jumped from 143KB to 1.13MB, and this new game I'm making is tiny at the moment.

Still, I'll be saving this thread so I can change between the two if I choose to.
Thanks again.

AMCerasoli

Member #11,955

May 2010

djchallis said:

does that mean you all use Code::Blocks?

I also use code::block, it's very practical and powerful.

Quote:

I was originally planning on using Code::Blocks but the Allegro 5 tutorial recommended I go with Visual Studio.

When I was editing the Wiki along with some folks I thought "what the hell, if it's easier than code::block..." But in the 84 years that I have in this community, I have seen Visual Studio presenting more problems than Code::Blocks, so I'll change that advice to something more realistic.

So do it, change to C::B you won't regret it. I'm planning now in two new tutorials:

Allegro and Code::Blocks in you USB, which will also give some advices about how to create an easy recoverable environments (backups).
Changing from different Allegro versions without doing all the process repeatedly.

Matthew Leverton

Supreme Loser

January 1999

djchallis said:

the .exe file has jumped from 143KB to 1.13MB

Yes, but that's smaller than the exe + all the dlls you needed previously.

You can use UPX to shrink the exe size if it bothers you.

Edgar Reynaldo said:

How did I know? I used grep for windows [grep -r -E "PathFindOnPathA" .*.*].

Or just search for PathFindOnPathA on Google (like I previously suggested), and it comes right up.

--
RTFM | Follow Me on Google+ | I know 10 people