Hi,
I know how to handle .dll of liballegro (alleg42.dll and so on)
1) it is create while building allegro
2) it can be distributed along with the program (in same directory as .exe)
3) or probably it can be in some... WINDOWS/system32/ (like c:/windows/system32/) direcotry, right?

and what aobut linux version of .dll - the *.so files?
1) they are also build while compiling the allegro library
2) how should I run distrbitue them along (assuming I realy want this, since my program is close-source, and I do not want to install liballeg in entire system, and so on)? IF I just copy *.so to sam directory when executable is, it dont work. How exacly should I startup an executable ./foobar telling it to look for SO libraries in "./" or in "./libs/linux/" and so on?
3) what was again that thingy to make SO installed globally in system? write some patch to some file and call ldconfig...?
4) what are usefull tools on that subject (like - how to check with exacly SO files are beeing used/needed)?

I think it's better to just statically link with Allegro and everything else that you need to. The downside is that your executables will be huge, but at least you're almost guaranteed they'll work everywhere...

I wonder.. Isn't just a dll the same as static linking, but it is ripped out of the exe and placed in it's own file?

EDIT: I mean, won't the dll be as huge as the exe file would have been when static linked?

But the user needs only to download the DLL once.

When static linking, some parts of Allegro is left out if it's not used (code wise) so the exe would be smaller than a dll/exe combo. But if your program is going to have more than one exe for whatever reason (like a separate map editor, and other tools) then the dll/exe combo will be smaller space wise.

No. Parts of a DLL/shared lib are put into shared memory space, so multiple processes can access the same memory area (smaller footprint and nice on CPU cache). However, if it's just a single process at the time, then I don't think there'd be a difference memory-wise.

That's not true anymore. Since you can dynamicly load the exe itself, the linker can't assume that unused code not directly referenced won't be used indirectly (ie. dlopen the running program and dlsym to grab any function/variable you want). UPX, at it's highest setting, will strip out unused code though, IIRC.

Depends. You can build a static version of Allegro, in which case you don't get the shared objects.

As a rule of thumb, you don't. If you do though, they should probably go to /usr/local/lib and be properly symlinked. I'm not familiar with the detailed conventions on this, you can probably google for it.
But again, as a rule of thumb, don't.

Some clarification: the programme isn't normally the one who does the loading of shared object files, that's the job of the programme that launches your programme, the loader ld (yes, the same one you use to link your programmes).
The loader looks in several locations preset in ld.so.conf. As a normal user you cannot alter this, so you need to be root to do that. For programmes I personally consider it bad form to do this anyway (I prefer it creates symlinks in /usr/lib or something like that).
In addition to this, the loader checks the directories listed in the LD_LIBRARY_PATH environment variable. For instance, doing export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/lib will add the user's personal lib directory to the search path. This should be your prefered way to tell the loader where to find the files. Just have a line like that and a call to the executable of your programme in a shellscript and you should be fine.
This method has the advantage that the programme can be installed by a normal user on his or her own account.

Make sure the directory is in /etc/ld.so.conf and run ldconfig. Again, I consider this rather bad form personally and it makes it impossible for a normal user to install the programme.

ldd.

Is is possible to just make an archive of all of the so files required by a program and distribute that as well? Would the program be able to find the files in its own directory or would they have to be moved/copied somewhere?

If you start the program with a script that modifies LD_LIBRARY_PATH (I think? maybe it's something else..), then calls the real executable, it should work fine. And as long as you start a script with #!/bin/sh or some other shell, the modified var will only be modified inside the script (eg. the rest of the system will be unaffected).