Re: [AD] Dynamic Linking

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


On Sat, Jul 10, 1999 at 02:08:06AM +0100, I wrote:
> 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.

Tonight I've put sharing options in the configure script; they
still need a little tweaking but I should upload them early
tomorrow.  My changes are somewhat tied to gcc, because that's
the only way to do shared libraries that I know; maybe we should
use libtool instead, but I don't know much about it, and there's
something about the way in which it works that makes me worry
about it making mistakes... but that's probably irrational.

In doing this I've been reminded that as a last resort we can
use the C versions of the assembler functions, where available,
and compile with -fPIC.  There'll be a significant speed loss
though.

Speaking of which, I cmplogged some profiles in VGA 320x200x8bpp
mode -- the first is a static library, the second is shared.
Most functions seem identical in speed; the shared library is
10%-20% slower on putpixels, 10% slower on lines, but 25%-100%
faster on circles (but not ellipses) and 13% faster at
draw_rle_sprite; all other results are within the range
95%-105%.  Deja vu, Shawn?  I don't really trust these results
much...  The comparison is attached, anyway.

If the logs are to be trusted, I'm quite happy with the majority
of the results.  It'll be worth working out why putpixel and
hline are so slow now though.

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

Of course, that wasn't much of a test because the anticipated
problems only occur when the library is mapped at different
locations in the two processes, which won't be the case here.
But I have also tried running the demo game at the same time as
the test program, now, without problems.

Now, though, I have found something close to a solution -- but I
can't find any real documentation on it.  The glibc library does
something odd with its libc.so file -- the file isn't a symlink
to the library, it's a text file:

    /* GNU ld script
       Use the shared library, but some functions are only in
       the static library, so try that secondarily.  */
    GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

So, we could do the same thing, putting all the PIC code in
the shared library and the non-PIC code in a static library.
Provided this code is small and doesn't call other libraries,
we get both the benefits of a shared library that I mentioned
above (i.e. we can distribute a selection of shared libraries
for end-users to install on their systems, and game binaries
won't be bloated).

-- 
George



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