Re: DRI fixes for libdl module loader

[Adam J. <aj...@nw...>]

=2D----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 s=
ome=20
cases without build-time hacks (though granted said build-time hack has=20
already been written [1]).  Partly because the elfloader doesn't have this=
=20
ability and code-compatibility with both loaders is desirable.  And partly=
=20
because if we let the runtime linker handle that, we may as well go whole h=
og=20
and do away with LoadSubModule() altogether.

I just don't feel that's the right approach yet.  We've gotten on rather we=
ll=20
with having modules that know their needs at runtime, and the minimal=20
solution to make them work with the dlloader is to eliminate weak data=20
references, which is ~80 lines of diffs.  This works iff the relationship=20
between modules is well-defined.  The relationship between libglx and libdr=
i=20
is not well-defined yet, but fixing that is a matter of another LoadSubModu=
le=20
call in the right place.  I'm just asking where people think the right plac=
e=20
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 aroun=
d=20
for a while.

=2D - ajax

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

iD8DBQFA//PYW4otUKDs0NMRAuKKAKDeCPguXUJ73zEN8FrTQCu925WMtgCcC4TN
x3zsFSzGXs4fdpHdbMtbBNk=3D
=3DPALY
=2D----END PGP SIGNATURE-----