4.4.1 and 4.9.x are missing the make files and fix.bat. The precompiled binaries for mingw are for ver 3.3 (I'm using 3.4.5). The allegro team has failed to make this easy for new folks to get into like they did in the past. This isn't good guys.
It's still in beta.
It's not missing them. Allegro has switched to CMake. Read the instructions, then come back with valid comments and/or questions.
Alright then. There are multiple conflicting instructions online. It's difficult for a new user to get a grip on how to do set up. Allegros biggest draw is how easy it is for new users, but changing the way it gets set up but not changing the instructions for setup sends mixed signals.
Maybe I've just caught things in a weird point, and I don't mind that. I just wanted to make the dev team aware.
Of course there are ~15 years of incompatible Allegro tutorials on the Internet that pre-date Allegro 4.4/4.9. The Allegro development team is only responsible for the instructions that come with the library. Those instructions are kept up-to-date.
Anyway, when 5.0 is ready, there will be binaries for the popular platforms. Most people won't have to bother with compiling Allegro, so I wouldn't really worry about anything.
I remember getting stuck on the instructions saying to mkdir build, then cd build, then something about parent directory (which I missed) for cmake command.
The only thing I don't like about the CMake system is that it means I have to install CMake - which I don't intend to use for anything other than compiling Allegro.
There may well be conflicting sets of instructions about how to install Allegro, but I found it easy enough to just follow the instructions that are included in the download. I wouldn't look for other instructions unless I got stuck. There is definitely room for improvement though.
Hm, CMake should offer a bundlable binary.
The allegro team has failed to make this easy for new folks to get into like they did in the past.
That is true man... I spend a lot of time learning new things this time, and i made a videotutorial for the community... but no one know it (the videotutorial)...
This is the Link: Installing Allegro 4.9.19 With Binaries
Why are so many people so afraid of new things? Seriously, it isn't hard. It might be tedious if you plan to build all the dependencies yourself, but if all you want is allegro then you can SKIP them ALL. And if you do, the building is similar to how it was before. Just it uses CMake instead of hand rolled makefiles, and autoconf.
and i made a videotutorial for the community... but no one know it
You can always put it on Youtube. It's likely to be searched more easily. Or you can make an article in the Wiki, but there is a good amount of them right now.
About getting it to be "easy", some things people should understand:
- It's still in beta. The devs might start making easier tutorials when the amount of dependencies needed is defined, and even if CMake is going to be used as the final build system.
- Likely, the 4.9 branch is hard to setup on Windows AFAIK. As Matthew already said, binaries will likely be distributed for the most common compilers. If conflicts like this happen:
the precompiled binaries for mingw are for ver 3.3 (I'm using 3.4.5).
then new binaries will be released.
Seriously, it isn't hard.
Just it uses CMake instead of hand rolled makefiles, and autoconf.
I don't know what any of those are! Or why that makes any kind of difference to me!
but if all you want is allegro then you can SKIP them ALL.
I don't want to have just allegro. I want to make games! I'm not interested in learning a build system and configuring makefiles with cmake folder build environment blabadie bloops subsystem platform altercations. That's what I see. Building things is a whole other language.
Why are so many people so afraid of new things?
I'm not afraid of it. I just don't want to have to learn all the ins and outs of a system of which I only need to accomplish one thing.
It's just frustrating, Thomas. You talk about it and it seems easy to you because you understand the process. I don't. It's not something you can just pick up.
And I'm not a noob. I've been using allegro for more than 5 8 years now. Every time it comes time to build, it's a pain in the ass. There's always 50 steps and 50 switches and readmes and downloads and version conflicts. Not to mention when you can finally get it to work, there's that looming feeling that you didn't do it right and there's something wrong with the build that's going to come up later and bite you in the ass.
I'm sorry, I'm grumpy. I had some bad pizza.
I don't know what any of those are!
Then how did you ever build Allegro 4? On windows it used hand rolled (evil) makefiles, and on unix, it used autoconf to generate a configure script which generated makefiles.
I don't want to just have allegro. I want to make games! I'm not interested in learning a build system
Thats too bad. you'll either have to learn it, or wait till someone builds a binary for you, which could take some time.
It's just frustrating, Thomas. You talk about it and it seems easy to you because you understand the process. I don't. It's not something you can just pick up.
I didn't know CMake prior to allegro picking it up. I didn't learn CMake till well after allegro switched to it actually. So obviously it is something you can just pick up. I'm not the brightest bulb in the box you know.
And I'm not a noob. I've been using allegro for more than 5 years now.
But you act like one. If you're afraid to learn new things, you're not going to get very far, very fast.
Either stick with the binaries that people put up eventually, or learn how to actually build allegro. Those are the only two choices.
Building Allegro with all of its addons is actually easier that it was before. Now that we include many addons, they use the same build system, and build with allegro. Before you had to go download a bunch of separate packages, all of which used a separate hand made build system which you'd have to learn separately, and build them all separately. All you have to do now is tell cmake where the source is, where the build dir is, and hit "generate", then you just type "make", or in the case of MSVC, load up the newly generated .sln file.
It's not something you can just pick up.
Wait wait, what CMake version are you using? There's a very easy to use GUI version.
EDIT: You don't really need all addons. I could care less for flac support, so I don't build it.
Wait wait, what CMake version are you using? There's a very easy to use GUI version.
Exactly!! Apparently there's are versions I shouldn't be using?! CMake isn't a program that I usually use. People don't know these things.
All you have to do now is tell cmake where the source is, where the build dir is, and hit "generate", then you just type "make", or in the case of MSVC, load up the newly generated .sln file.
Alright! Let me just do that. Since that's 'all' I have to do.
Downloading Source.
Downloading CMake.
assuming the Windows Installer version is the one I want
Installing CMake
clicking "add CMake to the system PATH for all users" (That sounds like something that could screw me)
Opening CMake GUI
creating a new build folder
picking the "Visual Studio 9 Generator" since I just happened by the information that the VS10 version doesn't work correctly, and I should instead be using the 9 generator.
Trying to build
What Information do I need to know? All I have at this point is "It doesn't work." I'm completely in the dark. I even tried all the other MSVC Generators (the poking in the dark technique).
Please bear with me. I'm actually in a really goofy mood.
I'm not the brightest bulb in the box you know.
Now that's not true. I've read some of your source code for the Canva5 lib.
On Windows, Allegro 4.2 came with MSVC project files that you open up and click build. There's nothing evil about that. It works every time with no fuss.
Allegro 5 is more difficult to build for MSVC, and I wouldn't recommend any average user to even bother doing it. (It's not like it's extremely hard, but it's an unnecessary evil.)
Under Linux, it's hardly a nuisance at all.
What Information do I need to know? All I have at this point is "It doesn't work." I'm completely in the dark. I even tried all the other MSVC Generators (the poking in the dark technique).
I never use the GUI version. It doesn't ever seem to work.
Open MSVC's Command Prompt.
set LIB=%LIB%;c:\path\to\third\party\libs
set INCLUDE=%INCLUDE%;c:\path\to\third\party\headers
cd allegro
mkdir build
cd build
cmake .. -G "Visual Studio 9 2008"
Laugh at all the missing dependencies.
Open MSVC project file. Build.
What Information do I need to know? All I have at this point is "It doesn't work." I'm completely in the dark. I even tried all the other MSVC Generators (the poking in the dark technique).
It looks to me like you haven't setup MSVC properly? CMake seems to be complaining that it can't find MSVC 2008. But since I don't use MSVC, I really can't help much.
Now that's not true. I've read some of your source code for the Canva5 lib.
Oh come now, its nothing fancy. In fact I'm pretty sure I'm doing some if it horribly wrong Got some major bugs to fix in the way transformations are handled. And figure out a way to "clip" to arbitrary shapes, rather than right angled quadrilaterals (squares and rectangles
).
On Windows, Allegro 4.2 came with MSVC project files that you open up and click build. There's nothing evil about that. It works every time with no fuss.
Allegro 5 should probably come with one as well.
append:
Please bear with me. I'm actually in a really goofy mood.
No problem so long as you don't take my grouchiness too seriously.
It looks to me like you haven't setup MSVC properly?
Exactly!! Apparently there's some way I shouldn't be setting up MSVC?! So, now "build allegro" is "figure out all the millions of possible things that could be wrong with your MSVC install with the looming feeling that it might have nothing to do with the problem." That's the definition of something that's a pain in the ass
I never use the GUI version. It doesn't ever seem to work.
Exactly!!
OK... Back to seriousness.
What are these lines:
set LIB=%LIB%;c:\path\to\third\party\libs set INCLUDE=%INCLUDE%;c:\path\to\third\party\headers
Are these the libraries that Allegro requires to build? Do I need to get these from another place and build them? (And, this is allegro 5, right?)
Seriously, though. I've gone this far. I'm energized. I'm goin' all the way.
Need some theme music:
It's not something you can just pick up.
You don't need to know how to use cmake, really. You just need to know how to follow the instructions that come with A5. I've built several of the 4.9.x builds (and 4.4) and I don't really know how cmake works.
Under Linux, it's hardly a nuisance at all.
It's very easy under Windows as well if you use MinGW.
Are these the libraries that Allegro requires to build? Do I need to get these from another place and build them? (And, this is allegro 5, right?)
Yes. I put all the third party libraries (e.g., dumb.lib) in a single lib folder outside of my main MSVC lib folder. I think it's easier to keep organized that way.
Then if CMake knows to look there (via the LIB variable), they will be detected during the cmake process.
Exactly!! Apparently there's some way I shouldn't be setting up MSVC?! So, now "build allegro" is "figure out all the millions of possible things that could be wrong with your MSVC install with the looming feeling that it might have nothing to do with the problem." That's the definition of something that's a pain in the ass
Theres a reason I don't use MSVC at all.
It's very easy under Windows as well if you use MinGW.
I was using MinGW and Code::Blocks before MSVC, but MSVC is so nice (the IDE, I mean). All the other environments I've used don't come close.
Then if CMake knows to look there (via the LIB variable), they will be detected during the cmake process.
So, I'm assuming I could build the "vanilla" allegro without having to set the LIB and INCLUDE paths at all? I don't want to get ahead of myself so I'll try that first.
Aaaannnnd fail:
Setting environment for using Microsoft Visual Studio 2010 x86 tools. c:\program files (x86)\microsoft visual studio 10.0\vc\bin>cd/ c:>cd users c:\Users>cd mark c:\Users\Mark>cd desktop c:\Users\Mark\Desktop>cd allegro c:\Users\Mark\Desktop\allegro>mkdir build c:\Users\Mark\Desktop\allegro>cd build c:\Users\Mark\Desktop\allegro\build>cmake .. -G "Visual Studio 9 2008" -- Check for working C compiler using: Visual Studio 9 2008 -- Check for working C compiler using: Visual Studio 9 2008 -- broken CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTes tCCompiler.cmake:52 (MESSAGE): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/Mark/Desktop/allegro/build/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual C++ 2010 Express Version 10.0.30319.1. Copyright (C) Microsoft Corp. All rights reserved. Solution file 'C:\Users\Mark\Desktop\allegro\build\CMakeFiles\CMakeTmp\CMAKE_TRY_COMPILE.sln ' is from a previous version of this application and must be converted in order to build in this version of the application. To convert the solution, open the solution in this version of the application. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:30 (project) -- Configuring incomplete, errors occurred! c:\Users\Mark\Desktop\allegro\build>
I really don't know how to interpret any of those error messages.
Use -G "Visual Studio 10" instead.
Use -G "Visual Studio 10" instead.
Isn't that supposed to not work due to CMake making broken VS 10 projects?
Apparently there's are versions I shouldn't be using?!
That's not what I said. The GUI version is just easier to use. ML says it doesn't work sometimes, that hasn't happened to me so far. But who knows.
c:\Users\Mark\Desktop\allegro\build>cmake .. -G "Visual Studio 10" CMake Error: Error: generator : Visual Studio 10 Does not match the generator used previously: Visual Studio 9 2008 Either remove the CMakeCache.txt file or choose a different binary directory. c:\Users\Mark\Desktop\allegro\build>
Ok, erasing the whole allegro folder because I don't know what other droppings are left in there. And re-extracting from the zip... making build folder and...
c:\Users\Mark\Desktop\allegro\build>cmake .. -G "Visual Studio 10" -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 -- Check for working CXX compiler using: Visual Studio 10 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Using VCINSTALLDIR: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC -- Allowing MSVC to use SSE instructions -- Check if the system is big endian -- Searching 16 bit integer -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of unsigned short -- Check size of unsigned short - done -- Using unsigned short -- Check if the system is big endian - little endian -- Looking for include files ALLEGRO_HAVE_DIRENT_H -- Looking for include files ALLEGRO_HAVE_DIRENT_H - not found. -- Looking for include files ALLEGRO_HAVE_INTTYPES_H -- Looking for include files ALLEGRO_HAVE_INTTYPES_H - not found. -- Looking for include files ALLEGRO_HAVE_LINUX_JOYSTICK_H -- Looking for include files ALLEGRO_HAVE_LINUX_JOYSTICK_H - not found. -- Looking for include files ALLEGRO_HAVE_STDBOOL_H -- Looking for include files ALLEGRO_HAVE_STDBOOL_H - not found. -- Looking for include files ALLEGRO_HAVE_STDINT_H -- Looking for include files ALLEGRO_HAVE_STDINT_H - found -- Looking for include files ALLEGRO_HAVE_SYS_IO_H -- Looking for include files ALLEGRO_HAVE_SYS_IO_H - not found. -- Looking for include files ALLEGRO_HAVE_SYS_STAT_H -- Looking for include files ALLEGRO_HAVE_SYS_STAT_H - found -- Looking for include files ALLEGRO_HAVE_SYS_TIME_H -- Looking for include files ALLEGRO_HAVE_SYS_TIME_H - not found. -- Looking for include files ALLEGRO_HAVE_TIME_H -- Looking for include files ALLEGRO_HAVE_TIME_H - found -- Looking for include files ALLEGRO_HAVE_SYS_UTSNAME_H -- Looking for include files ALLEGRO_HAVE_SYS_UTSNAME_H - not found. -- Looking for include files ALLEGRO_HAVE_SYS_TYPES_H -- Looking for include files ALLEGRO_HAVE_SYS_TYPES_H - found -- Looking for include files ALLEGRO_HAVE_SOUNDCARD_H -- Looking for include files ALLEGRO_HAVE_SOUNDCARD_H - not found. -- Looking for include files ALLEGRO_HAVE_SYS_SOUNDCARD_H -- Looking for include files ALLEGRO_HAVE_SYS_SOUNDCARD_H - not found. -- Looking for include files ALLEGRO_HAVE_MACHINE_SOUNDCARD_H -- Looking for include files ALLEGRO_HAVE_MACHINE_SOUNDCARD_H - not found. -- Looking for include files ALLEGRO_HAVE_LINUX_SOUNDCARD_H -- Looking for include files ALLEGRO_HAVE_LINUX_SOUNDCARD_H - not found. -- Looking for include files ALLEGRO_HAVE_OSATOMIC_H -- Looking for include files ALLEGRO_HAVE_OSATOMIC_H - not found. -- Looking for getexecname -- Looking for getexecname - not found -- Looking for mkstemp -- Looking for mkstemp - not found -- Looking for mmap -- Looking for mmap - not found -- Looking for mprotect -- Looking for mprotect - not found -- Looking for sched_yield -- Looking for sched_yield - not found -- Looking for stricmp -- Looking for stricmp - found -- Looking for strlwr -- Looking for strlwr - found -- Looking for strupr -- Looking for strupr - found -- Looking for sysconf -- Looking for sysconf - not found -- Looking for fseeko -- Looking for fseeko - not found -- Looking for ftello -- Looking for ftello - not found -- Check size of _Bool -- Check size of _Bool - failed -- Performing Test ALLEGRO_HAVE_PROCFS_ARGCV -- Performing Test ALLEGRO_HAVE_PROCFS_ARGCV - Failed -- Performing Test ALLEGRO_HAVE_SV_PROCFS_H -- Performing Test ALLEGRO_HAVE_SV_PROCFS_H - Failed -- Performing Test ALLEGRO_HAVE_VA_COPY -- Performing Test ALLEGRO_HAVE_VA_COPY - Failed -- Check if constructors are supported - no -- Found DINPUT: C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Include -- Could NOT find DXGUID (missing: DXGUID_LIBRARY) CMake Error at CMakeLists.txt:598 (message): Windows port requires DXGuid (not found). -- Configuring incomplete, errors occurred! c:\Users\Mark\Desktop\allegro\build>
Apparently "Windows port requires DXGuid (not found)". I'm assuming all the other "not founds" aren't required to build vanilla.
[edit] sorry, I had copy/pasted the whole terminal output. Edited to only include relevant output.
I've been very impressed with the latest KDevelop release. I've pretty much switched to it (and I hate IDEs). Its not perfect, but it is very nice. I think it might run on windows if you're interested. Then you can have a good IDE and an easy to use Allegro
Isn't that supposed to not work due to CMake making broken VS 10 projects?
It builds Allegro, but everything is named wrong. I was going to spoil his fun after he thought it was working.
Windows port requires DXGuid (not found)
Probably found in the DirectX SDK.
Probably found in the DirectX SDK [www.microsoft.com].
It found DInput, which is also in DX...
That comes in the Platform SDK (and perhaps DX SDK too).
I've been very impressed with the latest KDevelop release.
Now, "build allegro" is "learn a whole new IDE"
It builds Allegro, but everything is named wrong. I was going to spoil his fun after he thought it was working.
I'm really enjoying this . I'll just pretend I didn't read that last part (as not to ruin the surprise).
Probably found in the DirectX SDK [www.microsoft.com].
8 minutes remaining on a 572MB file, which will hopefully contain a file I need. This is awesome
Now "build allegro" is "learn an whole new IDE"
No. It was just a suggestion.
8 minutes remaining on a 572MB file, which will hopefully contain a file I need. This is awesome
Not our fault you use MSVC
8 minutes remaining on a 572MB file, which will hopefully contain a file I need. This is awesome
You are complaining about 8 minutes? You know I'd normally need an hour to do something like that.
HOLY! 500+MB download for DirectX SDK? I didn't know it was THAT big. I knew the Windows SDK was big (I think it reaches the 1GB point, if not over)
You are complaining about 8 minutes? You know I'd normally need an hour to do something like that.
Well, I'm not complaining about the 8 minutes part.
OK. So I downloaded and installed the DirectX SDK and ran cmake again but it produced the same errors. The SDK installed into the folder "Microsoft DirectX SDK (June 2010") while the cbuild appears to be looking in the "Microsoft SDK" folder. So I'm going to copy the dxguid.lib from the previous folder (there is only the dxguide.lib, no dxguid.h file so hopefully that doesn't screw me) and I'm just going to... drop it in the same folder where it found DINPUT (?).
And... deleting the last build attempt in case there are bad droppings... ...creating the build folder... and...
Hey! It worked!
Ok. Before I do anything else, I'm going to copy all the files in the build/ folder. Because something else is going to go wrong when I try and run this ALL_BUILD, or INSTALL, or which ever one and it might leave droppings... (this is the part where paranoia sets in )
I'm going to open ALL_BUILD and try to build...
And I cannot build the solution unless the allegro source is beneath the build folder... so.... copying the whole allegro folder and... Build > Build Solution...
It's working!
End result is
Build: 98 succeeded, 2 failed, 0 up-to-date, 1 skipped
I don't know which ones failed, but there are libs and dlls in the lib folder. Though the dlls are named "allegro_color-4.lib" for example. There are 12 lib files and only 10 dll files. allegro-4.lib (should be allegro-4.9.lib) is missing.
It appears that allegro and allegro_audio did not compile.
OK, when trying to build just allegro (instead of Build Solution), I get the following errors:
1>------ Build started: Project: allegro, Configuration: RelWithDebInfo Win32 ------ 1> Creating library C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro.lib and object C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro.exp 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_Button 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_POV 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_POV 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_Slider 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_Slider 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RzAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RzAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RyAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RyAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RxAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RxAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_ZAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_ZAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_YAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_YAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_XAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_XAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _IID_IDirectInputDevice8A 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _IID_IDirectInput8A 1>C:\Users\Mark\Desktop\allegro\build\lib\RelWithDebInfo\allegro-4.dll : fatal error LNK1120: 11 unresolved externals ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
The other one that didn't build is allegro_audio (which also contains what look like DirectX errors)
1>------ Build started: Project: allegro, Configuration: RelWithDebInfo Win32 ------ 1> Creating library C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro.lib and object C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro.exp 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_Button 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_POV 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_POV 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_Slider 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_Slider 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RzAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RzAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RyAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RyAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_RxAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_RxAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_ZAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_ZAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_YAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_YAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _GUID_XAxis 1>dinput8.lib(dilib3.obj) : error LNK2001: unresolved external symbol _GUID_XAxis 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _IID_IDirectInputDevice8A 1>wjoydxnu.obj : error LNK2001: unresolved external symbol _IID_IDirectInput8A 1>C:\Users\Mark\Desktop\allegro\build\lib\RelWithDebInfo\allegro-4.dll : fatal error LNK1120: 11 unresolved externals 2>------ Build started: Project: allegro_audio, Configuration: RelWithDebInfo Win32 ------ 2> Creating library C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro_audio.lib and object C:/Users/Mark/Desktop/allegro/build/lib/RelWithDebInfo/allegro_audio.exp 2>dsound.obj : error LNK2001: unresolved external symbol _IID_IDirectSoundBuffer8 2>C:\Users\Mark\Desktop\allegro\build\lib\RelWithDebInfo\allegro_audio-4.dll : fatal error LNK1120: 1 unresolved externals ========== Build: 0 succeeded, 2 failed, 1 up-to-date, 0 skipped ==========
[edit] I'm copying dinput8.lib from the directx install folder, and putting it in the msvc libs folder. Didn't make a difference. There is already a dinput8.lib located in the path where it was looking (which was not in msvc's lib folder).
The SDK installed into the folder "Microsoft DirectX SDK (June 2010") while the cbuild appears to be looking in the "Microsoft SDK" folder
Adding June/lib/x86 to your %LIB% and June/include to your %INCLUDE% should do the trick.
SET LIB=June\lib\x86;%LIB%;c:\mylibs SET INCLUDE=June\include;%LIB%;c:\mylibs
Something like that. It searches in order, so I'd put the new DX first.
Put that in a .bat file. Get your c:\mylibs dependencies all built. Then building each version of Allegro 4.9 isn't so bad.
Just a little motivation.
{"name":"HanginThereMP.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/4\/c4d522dae8e199f209bc20569d9cccde.jpg","w":750,"h":600,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/4\/c4d522dae8e199f209bc20569d9cccde"}
How do I build an MSVC project from within the console? Or, how do I set LIB and INCLUDE from within the IDE so it builds with those vars SET. I created a bat file with these two lines:
SET LIB=c:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\lib\x86;%LIB%;c:\mylibs SET INCLUDE=c:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\include;%LIB%;c:\mylibs
Though I'm not sure about where I should be running it, if running it from the VS Command Prompt would affect the current project environment, etc. Of my guesses, building allegro or allegro_audio returned the same errors.
Just a little motivation.
Nice. I like the fitting analogy of how that cat could be falling to his death.
Why are so many people so afraid of new things?
Because one time we tried something new and it went bad. Now we know that trying new things leads to bad.
http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation
Especially for one sample.
One time someone linked to a fake wikipedia article. Now I can't know if yours is true, so I will ignore it.
How do I build an MSVC project from within the console? Or, how do I set LIB and INCLUDE from within the IDE so it builds with those vars SET.
You don't do either. After cmake creates the MSVC project, you just open it up. All the locations are hard-coded.
You can run the batch file from the console the next time you need to build Allegro.
It is possible to add include/lib folders to your IDE's search path, which is useful when you are building your own projects. Just search the menus to find out where to do it.
Because one time we tried something new and it went bad. Now we know that trying new things leads to bad.
I used the mind-reading module of Allegro 5 to have my sig ready for this.
The devs might start making easier tutorials when the amount of dependencies needed is defined, and even if CMake is going to be used as the final build system.
The dependencies are very unlikely to change at this point. We will not be changing the build system.
As for tutorials, that's what we have a community for.
You don't do either. After cmake creates the MSVC project, you just open it up. All the locations are hard-coded.
Ah, I see. That makes sense. OK, so I created a batch file and ran it again before re-cmaking the msvc project files that I need to build allegro. This time it was able to build allegro and allegro_audio but for some reason did not build allegro_ttf and allegro_physfs. It makes sense because the dependencies are required, but why was it able to build it before? Odd.
Also, is there a complete list of dependencies somewhere that I can reference?
So here's the general procedure (please check my work):
The allegro source download, in addition to containing the source itself, also includes a bunch of other files that are used by CMake.
CMake is a program that takes those files and creates new files taylor-made for your compiler (MinGW, MSVC, Linux, etc).
These taylor-made files are created to make building on your system easier. And they are the ones you actually use to build allegro.
In addition to building "vanilla" allegro, you'll want to also build with the addon libraries.
You'll need to build those "dependencies" before you build allegro, otherwise your allegro build will not be correctly configured to use those addons.
It's easy on every system except MSVC.
In Readme.txt
Library dependencies ==================== Allegro is divided into a core library and a number of addon libraries. The core library depends on certain libraries to function. If you don't have those, nothing will work. These are required for the core library: - DirectX SDK (Windows only) You can get this for MSVC from the Microsoft web site (large download). Alternatively, smaller downloads for MSVC and MinGW are available here: <http://trent.gamblin.ca/dx/> Some of those are originally from: <http://www.g-productions.net/list.php?c=files_devpak> - X11 development libraries (Linux/Unix only) The libraries will be part of you Linux distribution, but you may have to install them explicitly. - OpenGL development libraries (except on Windows) The addons, too, may require additional libraries. Since the addons are strictly optional, they are not required to build Allegro, but a lot of functionality may be disabled if they are not present. Windows users may find some precompiled binaries from <http://gnuwin32.sourceforge.net/>. You need to get the `bin` and `lib` packages. The `bin` packages contain DLLs, and the `lib` packages contain the headers and import libraries. Mac users may find some dependencies in Fink or MacPorts. <http://www.finkproject.org/> and <http://www.macports.org/> Linux users likely have all the dependencies already, except PhysicsFS and DUMB. If your distribution uses separate development packages, they will need to be installed. The packages are probably named *-dev or *-devel. These are the dependencies required for the addons: - libpng and zlib, for PNG image support (Unix and MinGW only) Home page: <http://www.libpng.org/pub/png/> Windows binaries: <http://gnuwin32.sourceforge.net/packages/libpng.htm> - libjpeg, for JPEG image support (Unix and MinGW only) Home page: <http://www.ijg.org/> Windows binaries: <http://gnuwin32.sourceforge.net/packages/jpeg.htm> - FreeType, for TrueType font support. Home page: <http://freetype.sourceforge.net/> Window binaries: <http://gnuwin32.sourceforge.net/packages/freetype.htm> - Ogg Vorbis, a free lossy audio format. (libogg, libvorbis, libvorbisfile) Home page: <http://www.vorbis.com/> - FLAC, a free lossless audio codec. (libFLAC, libogg) Home page: <http://flac.sourceforge.net/> - DUMB, an IT, XM, S3M and MOD player library. (libdumb) Home page: <http://dumb.sourceforge.net/> - OpenAL, a 3D audio API. The audio addon can use OpenAL, although the 3D capabilities aren't used. <http://kcat.strangesoft.net/openal.html> On Mac OS X, OpenAL is *required* but should come with the OS anyway. On Linux and Windows, OpenAL will only be used if you request it, hence there is no reason to install it specifically. - PhysicsFS, provides access to archives, e.g. .zip files. Home page: <http://icculus.org/physfs/> On Windows it may be a pain to place all these libraries such that they can be found. Please see the README_cmake.txt section on the "deps subdirectory" when the time comes.
The dependencies are very unlikely to change at this point. We will not be changing the build system.
That's good news I guess.
In Readme.txt
Crap, I remember that now.
OK. It appears I was able to build vanilla allegro. The exe is looking for the dll named allegro-4.dll and not allegro-4.9.dll. I had thought that the filename of the file created was the only problem. Though using allegro-4.dll seems to work fine.
The addon header files seem to be located in different folders, (ala #include <allegro5/allegro_color.h> is not there) so needed to copy them from the allegro/addon/* folders into the allegro/include/ folder.
I'm placing the allegro libs in a folder separate from the MSVC folder and including them from a different location (as not to link the pre-built binaries I downloaded from allegro5.org that are already in the MSVC foler). And it seems to work!
Now that that's all done... time to create my first dependency.
The exe is looking for the dll named allegro-4.dll and not allegro-4.9.dll. I had thought that the filename of the file created was the only problem.
That's the CMake MSVC 10 bug.
The addon header files seem to be located in different folders, (ala #include <allegro5/allegro_color.h> is not there) so needed to copy them from the allegro/addon/* folders into the allegro/include/ folder.
Yes, that's another annoying CMake build issue on MSVC.
I'm placing the allegro libs in a folder separate from the MSVC folder and including them from a different location
That's a good habit to get into. I never put things into my MSVC lib folder.
Yes, that's another annoying CMake build issue on MSVC.
Has this bug been reported to CMake? Or should we think about doing so?
Has this bug been reported to CMake? Or should we think about doing so?
I haven't tested this, but if you set CMAKE_INSTALL_PREFIX it might work. As it is now, I think it's trying to install to "Program Files/MSVC" which is dumb and doesn't work anyway.
Edit: Looks like it might work, but:
------ Build started: Project: INSTALL, Configuration: RelWithDebInfo Win32 ------ -- Install configuration: "RelWithDebInfo" -- Installing: C:/allegro/install/lib/allegro.lib CMake Error at cmake_install.cmake:38 (FILE): file INSTALL cannot find "C:/allegro/4.9/build/lib/RelWithDebInfo/allegro-4.9.dll". C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command ""C:\Program Files\CMake 2.8\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P cmake_install.cmake C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1. ========== Build: 0 succeeded, 2 failed, 93 up-to-date, 0 skipped ==========
It cannot find "C:/allegro/4.9/build/lib/RelWithDebInfo/allegro-4.9.dll" because it was stupid and named it "allegro-4.dll".
I had absolutely no problems building A5 from SVN using VC 2008 this time around. Granted, it was tougher installing all of the dependencies I wanted for the addons.
WG