As multiple driver modules are loaded now on startup time (even if they
aren't actually used) we get something now that has not really been a
problem so far:
Name clashes.
We at SUSE additionally load radeonhd and radeon, and there the clashes
are most severe - I found 167 name clashes, which result in certain
death on r4xx cards with AtomBIOS, because some AtomBIOS routines from
radeonhd are called from the radeon driver, which have the same name but
subtly different semantics. Or values from tables from the one driver
are used with functions of the other. You get the picture.
The attached patch solves this issue on Linux - it uses RTLD_DEEPBIND
which is unfortunately not POSIX.1-2001 compatible.
Should this be added according to compile-time tests, or is there
another equivalent solution?
In the long term, explicitly exported symbols would probably be the
right way to go.
Matthias
--
Matthias Hopf <[email protected]> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [email protected]
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
Index: xorg-server-1.6.3.901/hw/xfree86/loader/dlloader.c
===================================================================
--- xorg-server-1.6.3.901.orig/hw/xfree86/loader/dlloader.c
+++ xorg-server-1.6.3.901/hw/xfree86/loader/dlloader.c
@@ -120,7 +120,7 @@ DLFindSymbol(const char *name)
}
if (!global_scope)
- global_scope = dlopen(NULL, DLOPEN_LAZY | DLOPEN_GLOBAL);
+ global_scope = dlopen(NULL, DLOPEN_LAZY | DLOPEN_GLOBAL | RTLD_DEEPBIND);
if (global_scope)
return DLFindSymbolLocal(global_scope, name);
@@ -136,9 +136,9 @@ DLLoadModule(loaderPtr modrec, int flags
int dlopen_flags;
if (flags & LD_FLAG_GLOBAL)
- dlopen_flags = DLOPEN_LAZY | DLOPEN_GLOBAL;
+ dlopen_flags = DLOPEN_LAZY | DLOPEN_GLOBAL | RTLD_DEEPBIND;
else
- dlopen_flags = DLOPEN_LAZY;
+ dlopen_flags = DLOPEN_LAZY | RTLD_DEEPBIND;
dlfile = dlopen(modrec->name, dlopen_flags);
if (dlfile == NULL) {
ErrorF("dlopen: %s\n", dlerror());
_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel
