Part of me is embarrassed to make this thread, but I am honestly stuck and need some help. I haven't used C/C++ too heavily in the past 10+ years, and it's showing. I can't get some old code of mine to compile. It relies on the Allegro library (4.4.2). It comes down to basic linker problems that I've simply been unable to resolve. I made a post on the Allegro forums, but they look half-dead: Basic linker problems with Allegro Anyone want to help me get going on this? For what it's worth, I'm trying to compile my FLOW source code (which is the basis for Zone Builder, which was never finished nor made into a public release). I want to experiment with it to see if I can get a basic level editor going for James Pond 3 (I already made a level viewer back in 2010). It may or may not get very far, but I that code that's just been sitting around. I feel like I should do *something* with it. But I can't even get started on anything if I can't do a simple compile. Anyway, I'd appreciate any help I can get!
I've never used allegro but I'm happy to help you debug any linker issues. How are you trying to link? Feel free to message me directly if you prefer.
Glitch was able to help get me up and running. Thanks! I'm considering releasing what I did for the Sonic 2 HD level editor back when L0st, Vince, Gambit, and the rest of the old team was in tact. It was initially called Gambit (for the person it was initially tailored to), and then a few months later I started calling it EditHD. Eventually I began writing it in such manner as to allow future support for other games. I named the codebase "FLOW", and from there I added support for the Sonic 2 disassembly and compiled that portion into a new program called Zone Builder. Anyway, releasing it would afford me the chance to get feedback as this is basically how a James Pond 3 level editor will be (aside from the fact that levels are constructed in a very different manner). I was trying it out last night for the first time in many years, and I think it really does a nice job. It's different from any other level editor I've ever used, which is half the point to be honest. But perhaps this is all off-topic. I'll create a new thread when the time comes.
Can I ask what the fix ended up being? Mostly so this doesn't end up being one of those "nvm fixed it" posts that drives people crazy when this thread inevitably shows up in someone's google search lol.
Good point. To the person using the search engine: I am so sorry if you're in this predicament. Don't pull your hair out, there's a fix! Solution: Don't use a 64-bit tool chain (mine is MinGW) to link precompiled Allegro library files (which are 32-bit). Also, I had to add a required #define specific to FLOW to link correctly. And finally, I had a bunch of "inline" keywords which weren't playing nice, so I removed them all.
Oh god I've run into this before with my 80960 escapades. Glad to see it sorted though, that's a fairly straightforward fix.
OP and biggestsonicfan: Pardon my obtuse question, but why not user MSVC on Windows instead of wrestling with minGW? Allegro supports VC Toolkit 2003, and surely it's a lot easier to configure with the OS's official compiler toolchain than to try and build using a port of GCC, which was originally designed around POSIX-flavored compiler-linker idioms.
While I like it well enough, it doesn't help in the way of supporting non-Microsoft platforms (at least the last time I checked, which admittedly has been many years now). Keeping things GCC friendly will allow the code to more readily and easily compile on Linux and other platforms. That's what's also nice about Java, although that's not even an option in this case.
Oh 80960 is a CPU architecture, nothing related to Allegro. As far as I know, there is no way to write code on Windows for Intel's 80960 CPUs unless you're using Windows 95 and a copy of CTOOLS, and no known Windows copies of CTOOLS exists on the internet today (save for the ones I have uploaded).
I thought that was what you meant, but I was more speaking toward saxman's multiple-OS problem, but DAMN! That sounds painful. Maintaining 2 separate build ecosystems sucks, but CMake does most of the work for you. You would still need to compile separately on Windows in addition to GCC to test changes, but then again you need to do that regardless because your minGW version is usually behind whichever GCC your Linux build is running- the warnings and errors may vary. I would strongly recommend just picking one platform (OS + compiler toolchain) and setting "-Wall -Werror" (or its equivalent) and keeping the default level of strictness everywhere else. I say all this as someone who spent 5 years working on a codebase that ran on Linux, Windows, AIX (PPC arch), Solaris (both x86 and SPARC), z/OS (Unix compatibility layer for IBM mainframes). I experimented with minGW as a way to unify the build system, and the problem from 35,000ft is that the Cygwin toolchain is an attempt to fit a square peg into a round hole. For example, symlinks don't exist on Windows (at least not until 10), NTFS is case-insensitive, the POSIX-style permissions don't work in native Windows (you're bound to NTFS ACLs), and POSIX syscalls don't neatly correspond 1 to 1 with Win32 API system calls. GNU make and bash have esoteric bugs as a consequence of these deviations. Pardon my unsolicited and possibly out of scope advice, but from experience I strongly recommend using CMake to automatically generate MSVC project files on Windows and Makefiles on all other platforms. On platforms supported by CMake (which also bootstraps itself with a separate build system on Windows), it is very good about doing the right thing by default without any furture intervention from the user. biggestsonicfan: But if I were to take an earnest stab at actually answering the question you asked, it would be this: The linker errors in that one forum you were seeing were probably not because the build system didn't pick up all the header and library files, but because some necessary macros were either undefined or incorrectly defined as saxman suggested. You may indeed be forced to modify src files and compile Allegro on your own, but try adding some "-D" compilation flags first so you're not forced to maintain your own fork of the src tree. "_WIN32" is only defined by the MSVC compiler and not by minGW, and you might be able to get away with "-D_WIN32" without any weird runtime side effect. This is just my $0.02. I ran into similar platform-specific macro problems when I tried porting a couple of libraries to FreeBSD, most notably TinyFileDialogs (completed) but also the Intel Floating Point Decimal library (incomplete, for the InteractiveBrokers C++ client).
