On Tue, Mar 25, 2003 at 11:33:31PM +0000, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Tue, Mar 25, 2003 at 11:18:45PM +0000, Keith Whitwell wrote: > > > >>>>My impression is that a patch trying to add a dlopen() call to one of > >>>>the xfree86 hosted ddx drivers would be rejected. > >>> > >>> > >>>Last I looked at the XF86 loader, it had some stuff in it that implied > >>>to me that it couldn't simply be treated as a wrapper for dlopen(), > >>>dlsym(), etc. > >>>I don't remember the details right now. > >> > >> > >>Yes, the XFree86 modules aren't regular .so type shared objects -- but > >>the thing we're interested in loading *is*, so we'd be forced to used > >>dlopen() to get it in the server. > > > > > >The XFree86 loader is capabile of loading .so or .a files. It has the > >support to resolve the symbols already. The dlloader.c and elfloader.c > >manage this respectively. > > > >Obviously the .so format being non-portable. > > > > OK, that changes things. > > Given that there's a portable way to load non-portable shared objects, I > don't see any barrier to proceeding.
Yes, but there's still an opportunity to provide a radeon_dri.a that is OS independent that could be loaded by libGL and the Xserver. Given that a .so and a .a is managed by the XFree86 loader, it's possible that libGL could be given the backwards compatibility to load older .so files too - although that may take a little more work to manage this compatibility. Alan. ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
