Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » .dll Vs .so

This thread is locked; no one can reply to it. rss feed Print
.dll Vs .so
Raf256
Member #3,501
May 2003

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)?

miran
Member #2,407
June 2002

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...

--
sig used to be here

Avenger
Member #4,550
April 2004

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?

ReyBrujo
Moderator
January 2001
avatar

But the user needs only to download the DLL once.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

MiquelFire
Member #3,110
January 2003
avatar

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.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

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?

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.

Quote:

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.

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.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Evert
Member #794
November 2000
avatar

Quote:

1) they are also build while compiling the allegro library

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

Quote:

2) how should I run distrbitue them along

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.

Quote:

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?

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.

Quote:

3) what was again that thingy to make SO installed globally in system? write some patch to some file and call ldconfig...?

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.

Quote:

4) what are usefull tools on that subject (like - how to check with exacly SO files are beeing used/needed)?

ldd.

Dark Nation
Member #1,642
November 2001
avatar

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?

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

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).

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Go to: