[…]
Don’t feel bad, you’re not alone. On my system, SDL_image
fails ./configure, hence guichan won’t compile. Other projects
configure, but then fail the make stage.
Did you ./configure --prefix=/usr ?
On some systems, you need to make sure all libs with interdependencies
are built with the same prefix, or they won’t find each others’
*-config scripts and stuff. Packages that don’t check for things
in ./configure usually fail when compiling instead, as a result of
missing headers. (The compiler just ignores the missing include and
tries to compile anyway, so you may get a million weird errors,
making it hard to spot the actual reason.)
Others configure, make, and install, but then crash and burn on
launch.
Are you using some non x86 or 64 bit x86 architecture? Most people
seem to be on 32 bit x86 - and it’s not exactly unusual to see stuff
that “used to work” break when you go 64 bit…
And then there’s this C++ ABI issue. Beware of “user oriented” distros
with weird or broken development tools, or none at all! (If you
install GCC from source, make sure you install a version that’s ABI
compatible with the one used for building your system’s C++ libs.)
(Despite what ID claims, Doom III will NOT run on Linux.)
Well, binary-only distros tend to have issues, but it runs fine here.
(Gentoo/AMD64; a native 64 bit system.)
The sad fact is that there’s a lot of crap out there produced by
parochial amateurs who assume that everyone has exactly the same
hardware and software installed as they do.
I think the main problem is that most people simply don’t have
sufficient knowledge about low level details like calling
conventions, shared library loading mechanisms, endian issues etc.
After all, most languages higher level than assembly language as
supposed to hide the details these issues are related to, so how are
people supposed to learn?
I find it amazing that people can actually learn serious programming
without starting with assembly language… People start flying
without knowing how to walk.
Even some pros (did I mention ID software?) can’t seem to make truly
cross-platform software.
For a moving target with a million flavors, like Linux, it’s very hard
to make binaries work everywhere. Even so, I’m surprized how well it
works, even on the non Red Hat distros I’ve been using the last few
years.
There are very few people like Sam, Bob Pendleton, David Olofson,
and others (not to slight anyone I haven’t mentioned) who have the
skill to produce software that will compile and run on most systems.
Well, I have a simple trick: Explicitly target at least two very
different platforms.
I develop everything on Linux, but I build and test most of my code
for or on Windows, and sometimes OS X. Just doing a build in a Win32
cross compiler with all warnings enabled can reveal both portability
issues and “sleeping bugs” that could potentially affect all
platforms.
It might actually be a good idea to develop on multiple platforms even
if the product is only planned for release on a single platform.
You’ll get more robust code that’s easier to reuse in future
projects.
BTW, I’m not one of them. I get bug reports about once a month from
someone running a ThunderThud X system with libusbfubar version 6
(or some such), and by golly, my software misbehaves on his system.
I get those too occasionally, especially after making substantial
changes - but considering the number of downloads, my inbox is
actually surprizingly quiet… 
The bottom line is, if you want a decent gui to use with SDL, you
may just have to write it yourself. And then don’t expect it to work
for anyone else.
Well, that would depend on what type of GUI toolkit you need, and what
you’re hacking, and why.
If you need all the “standard” widgets, proper windowing and whatnot,
you’re in for some serious design and hacking. You can learn a lot
from rolling your own GUI toolkit though, so if you’re not in a hurry
to get something out the door, why not? Otherwise, you’ll most
probably get done quicker if you pick up something that’s almost
there, and fix it.
If you need a simple menu (like the one in the original Doom, for
example), you might actually write that quicker than you can find
something suitable, get it to work, and integrate it with your code.
For some problems, it’s hard to come up with an API that
isn’t “bigger than the problem”…
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'On Saturday 27 January 2007 08:20, Jeff wrote:
Those issues are fairly easy to resolve, as are