Re: [AD] Distributing and maintaining a Linux Allegro application

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Friday 13 January 2006 07:17, Runesabre wrote:
> Linux is the sore spot.  I'm less confident it will be
> so easy with the Linux distribution.  I'm currently
> building and running my Allegro on Fedora Core 4.  I
> have no idea (yet) whether it will run on Fedora Core
> 3, 2 or 1, Red Hat 9.0 or Red Hat Enterprise Linux for
> that matter. 

I can confirm Allegro working on RH Enterprise, but I'm pretty sure you don't 
have to worry about any of the others. Linux should be Linux as far as most 
programmes are concerned. Actually, I'd go so far as to say that UNIX should 
be UNIX as far as most programmes are concerned.

> I also have no idea (yet) whether the 
> same build from my FC4 machine will produce an
> application that can also run on Debian, Gentoo,
> Mandriva, Slackware, SuSE or other popular Linux
> distributions. 

This is becoming more and more standard and doable, but I don't have much 
experience swapping binaries from one Linux version to another. I usually 
compile from sources anyway.

> And that's just the 32bit x86 
> versions.  There's also the 64bit versions and the ppc
> versions.  A worst case scenario is that I have to
> rebuild my application and generate a unique
> distribution for each flavor and CPU platform of Linux
> which quickly becomes a logistical nightmare. 

64 bit AMD and Intel PC's should be able to run 32 bit applications, but if 
you want a native port you'll have to provide it. Of course, for PowerPC and 
non-intel machines, you'll either have to do the same, or distribute from 
source. The latter is a fairly standard way of installing programmes in the 
UNIX world.

> Additionally, I also don't want to have to require my
> customers to install Allegro as a separate library as
> it seems Linux doesn't allow my application to use its
> own shared objects out of its local directory. 

It does sortof. You can set the LD_LIBRARY_PATH variable to include the 
directory containing the objectfile before staring your programme. You can 
use a shellscript to do that. It's a bit ugly though.

That aside, if you distribute a professional product on Linux (or *NIX), you 
should make sure that it follows some form of the File System Hierarchy. If 
you do that, you don't have the problem of loading shared objects from the 
local directory because they go in /usr/local/lib or some other standard 
location anyway.

> That 
> makes it harder to patch future changes as well as
> leaves me open to fielding compatibility problems
> arising from different versions of Allegro.

Stick to the 4.2.0 API and you'll be fine from an ABI point of view for all 
4.2 versions. You should also be fine for later versions as long as you stick 
to the documented API.

> My first thought is that statically linking should
> help alleviate much of the problem.

It's the next best thing to providing source.

> That leaves compatibility with whatever X11 
> support each customer has configured on their machine.

You can staticlink everything (for Allegro be sure to disable modules), 
including X11 libraries, and you shouldn't have that problem either. You can 
even go so far as staticlinking libc, in which case your programme should 
just work on any Linux installation. However, there may be licensing issues 
associated with staticlinking glibc, so be sure to check that.

> I'm hoping there's a way I can fairly easily manage to
> support a wide range of Linux distributions. 

The best (and easiest way) is through a source distribution. If you don't want 
to do that, staticlinking is your best bet. You may also want to look at the 
effort of having a `universal' Linux platform that most major distributions 
adhere to these days (I think), but I forgot the name of the initiative.

Evert