[Xorg] Re: DRI fixes for libdl module loader

[Adam Jackson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 22 July 2004 04:09, Keith Whitwell wrote:
> Can't this be expressed with the native library dependency mechanisms of
> the OS?  For instance, when you do 'ldd <somelibrary>', you get a list of
> other libraries it depends upon.  Why can't we use this native mechanism to
> express the dependencies you're talking about?

Yes it can, but I don't want to.  Partly because it's tough to do that in some 
cases without build-time hacks (though granted said build-time hack has 
already been written [1]).  Partly because the elfloader doesn't have this 
ability and code-compatibility with both loaders is desirable.  And partly 
because if we let the runtime linker handle that, we may as well go whole hog 
and do away with LoadSubModule() altogether.

I just don't feel that's the right approach yet.  We've gotten on rather well 
with having modules that know their needs at runtime, and the minimal 
solution to make them work with the dlloader is to eliminate weak data 
references, which is ~80 lines of diffs.  This works iff the relationship 
between modules is well-defined.  The relationship between libglx and libdri 
is not well-defined yet, but fixing that is a matter of another LoadSubModule 
call in the right place.  I'm just asking where people think the right place 
is.

> Similarly, tasks like module init and module cleanup can be handled by
> native mechanisms (if you're not already doing this), rather than by
> bolting on new code around dlopen().

I'm not already doing this; people seem to want the elfloader to hang around 
for a while.

- - ajax

[1] - http://freedesktop.org/bugzilla/attachment.cgi?id=176&action=view
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA//PYW4otUKDs0NMRAuKKAKDeCPguXUJ73zEN8FrTQCu925WMtgCcC4TN
x3zsFSzGXs4fdpHdbMtbBNk=
=PALY
-----END PGP SIGNATURE-----