Re: [AD] Dynamic Linking

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri, Jul 09, 1999 at 03:28:45PM -0500, Jason Wilkins wrote:
> Did anyone ever answer how we should handle drivers that require dynamic
> linking to other lower level librarys/drivers.  The problem was having a
> program that required that a person have all these libraries installed or
> it wouldn't run.

I haven't thought of any really good solution.  It's going to be
platform-dependent in any case.

> My thought was to link the libraries in on demand instead of linking with
> the import library.  It would require the drivers to load the libraries
> they need at run-time.

The problem with that is that all those functions end up going
through another level of indirection, which is inefficient, not
so much in terms of speed, but more in terms of needing a
register to hold the target address of the jump (but I could be
wrong).  I think it would end up worse than the system of import
libraries in Windows...  Anyway, yes, this is possible in Linux,
but I don't like it too much.

There is some light in the distance though -- if we get Allegro
working as a shared library, then people can have their own
version on their hard disk which is configured to match their
system (or rather, to match the libraries available on their
system).  We then `just' need a collection of prebuilt sharable
libraries for end users to install the one they want.  We could
end up with rather a lot -- Allegro, Allegro without X,
Allegro without GGI, Allegro without X or GGI, Allegro without
SVGAlib, ... that's eight configurations I can see so far.

I have been experimenting with a shared Allegro library.  It
seems to work (compile all the sources with -fPIC, create a
shared library instead of a normal archive, then link
executables to that instead of the static version).  The reason
I was investigating this was the size of an Allegro
distribution, with all executables compiled with debugging
information and a (static) debugging library linked into each
one.

The problem with shared libraries is that (apparently) they
require you to write position independent code (PIC, hence the
gcc option above).  That's easy enough for compiled C code (if
inefficient), but a large chunk of Allegro is assembly language
modules which weren't written with this in mind, and that's a
lot of code to convert.

I don't see any reason to require PIC unless multiple processes
share a single copy of the library in memory.  We don't
particularly need this, Allegro isn't *that* huge.  But I don't
know whether or not we can force a separate copy to be loaded
for each process using the library.  However, I did try
simultaneously running multiple dynamically linked copies of the
demo game, which worked without problems.

-- 
George



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/