[Xorg] Re: DRI fixes for libdl module loader

Jakub Stachowski qbast at go2.pl
Fri Jul 23 08:40:13 PDT 2004


Dnia czw 22. lipca 2004 19:05, Adam Jackson napisał:
> 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.
>

I suggest doing more radical changes, like link-time dependencies, getting rid 
of LoadSubModule() and init/cleanup functions in debrix (perhaps in separate 
branch). As it is not mature yet and still needs some time and work, no one 
would suffer from this - regular user would use 'stable' Xorg tree as usual 
and developers would have time to get used to changes and see how it works in 
reality.

> - ajax
>
> [1] - http://freedesktop.org/bugzilla/attachment.cgi?id=176&action=view
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg



More information about the xorg mailing list