Bug 137374 - xsload cannot load load _drv.so drivers
Summary: xsload cannot load load _drv.so drivers
Status: RESOLVED FIXED
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: X.Org (show other bugs)
Version: Alpha 3plus
Hardware: Other Linux
: P5 - None : Critical (vote)
Target Milestone: ---
Assignee: Stefan Dirsch
QA Contact: Stefan Dirsch
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-07 14:21 UTC by Marcus Schaefer
Modified: 2006-01-09 16:11 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Xorg dif (5.11 KB, patch)
2006-01-06 15:09 UTC, Marcus Schaefer
Details | Diff
Currently used patch by Marcus. (7.97 KB, patch)
2006-01-09 16:10 UTC, Stefan Dirsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Schaefer 2005-12-07 14:21:24 UTC
xsload was able to load the old style _drv.o drivers but with the new
file format based on dlopen the drivers cannot be loaded due to missing
symbols while loading the driver.

This will prevent xsload from working correctly which will prevent
all non X.Org driver like nvidia or ATI (fglrx) to be configured using
sax2
Comment 1 Stefan Dirsch 2005-12-07 14:26:59 UTC
We also use xsload to extract the driver options. Egbert, xsload is a fork of xf86cfg to load driver modules and extract some information from the module like options and vendor.
Comment 2 Stefan Dirsch 2005-12-07 14:58:39 UTC
How to build xsload
-------------------

... works only during "make World". :-(

- extract /work/SRC/all/BASE/xorg-x11/xsload.tar.gz
- apply the following patch

--- programs/Xserver/hw/xfree86/Imakefile.suse
+++ programs/Xserver/hw/xfree86/Imakefile     
@@ -88,12 +88,16 @@
 XF86CFGDIRS = xf86cfg xf86config
 #endif
 
+#if DoLoadableServer
+XSLOAD = xsload
+#endif
+
 SUBDIRS = os-support common $(I2CDIR) $(XAADIR) $(EXADIR) $(XF1BPPDIR) $(XF4BPP
DIR) \
           $(XF8_32BPPDIR) $(XF8_16BPPDIR) $(SHADOWFBDIR) drivers \
          $(LOADERDIR) $(VGAHWDIR) $(FBDEVHWDIR) $(RAMDACDIR) $(RACDIR) \
          $(DDCDIR) $(INPUTDIR) $(INT10DIR) $(VBEDIR) parser scanpci doc \
           dummylib $(XF86CFGDIRS) etc $(DRIVERSDK) $(XF8_32WIDDIR) \
-         getconfig
+         getconfig $(XSLOAD)
 
 #if !defined(OS2Architecture) && !defined(cygwinArchitecture)
 XORGCONFIG = XConfigFile
Comment 3 Stefan Dirsch 2005-12-08 03:48:22 UTC
See also shannon:/abuild/buildsystem.shannon.ms 

  /usr/src/packages/BUILD/xc/programs/Xserver/hw/xfree86/xsload.old
  /usr/src/packages/BUILD/xc/programs/Xserver/hw/xfree86/xsload

for first tries to fix this issue.
Comment 4 Stefan Dirsch 2005-12-12 13:30:50 UTC
Could we live with a workaround for Alpha4 for the nvidia driver
detection? Something like this?

libdir="lib"
test "$(arch)" == "x86_64" && libdir="lib64"
strings /usr/X11R6/$libdir/modules/drivers/nvidia_drv.so | \
  grep -q "NVIDIA dlloader X Driver"
if [ $? -eq 0 ]; then
  <code for proprietary driver>
else
  <code for dummy driver>
fi

Of course we should try to fix this for Beta1.
Comment 5 Marcus Schaefer 2005-12-12 14:23:07 UTC
Hmm, I don't like such an approach because I assume nobody will have a
look at xsload in that case
Comment 6 Stefan Dirsch 2005-12-12 14:28:10 UTC
Marcus, you're allowed to remove the workaround right after Alpha4 release. :-)
Comment 7 Marcus Schaefer 2005-12-12 14:50:52 UTC
Why do I always have to fix my own reports *grr* I added the
following workaround:

Index: sysp/script/vendor.pl
===================================================================
--- sysp/script/vendor.pl	(revision 971)
+++ sysp/script/vendor.pl	(working copy)
@@ -21,6 +21,11 @@
 # return <none>
 #
 	my $driver = $_[0];
+	# FIXME
+	# workaround for Bug: #137374, to be removed ASAP
+	if ($driver eq "nvidia") {
+		return "NVIDIA Corporation";
+	}
 	my $xsload = "/usr/X11R6/bin/xsload";
 	if (! -f $xsload) {
 		return ("<none>");
Comment 8 Stefan Dirsch 2005-12-12 14:56:21 UTC
Thanks! The bugreport remains open until we have a real fix.
Comment 9 Stefan Dirsch 2006-01-04 14:17:48 UTC
I've filed a bugreport against xorgcfg (which is affected as well) upstream
on fd.o.

  https://bugs.freedesktop.org/show_bug.cgi?id=5502
Comment 10 Egbert Eich 2006-01-05 13:04:38 UTC
Real fix looks difficult.
dlopen() needs to resolve those symbols despite RTLD_LAZY or will fail.
All offending symbols I saw are provided by core server. 
You need to add dummys. NOTE: dlopen fails right after first missing symbol. 
more -> schwab.
Comment 11 Marcus Schaefer 2006-01-05 13:14:56 UTC
Egbert, thanks for investigating this. I tried to compile an example
but there are lots of function I have to write a dummy for to get that
compiled. I think it doesn't make sense to use that xsload system any longer

Thanks again for looking at it too
Comment 12 Matthias Hopf 2006-01-05 15:47:11 UTC
This seems to be a *long* pending bug in libdl. However, this is just a rough guess from the documents I scanned and the discussions I had. Hopefully Andres can bring some light into this issue when he's back from holidays.
Comment 13 Egbert Eich 2006-01-05 16:07:29 UTC
Grr. One may use the dixsym.c, fontsym.c, misym.c and extsym.c to create dummies for these. This may be a wrokable solution that will help resurrect xorgcfg, too.
It will be ugly - but will render xorgcfg and friends only slightly uglier than they already are.
Comment 14 Marcus Schaefer 2006-01-06 15:08:20 UTC
I made a patch for the loader to be able to call

  X -showopts

Please have a look
Comment 15 Marcus Schaefer 2006-01-06 15:09:17 UTC
Created attachment 62179 [details]
Xorg dif
Comment 16 Stefan Dirsch 2006-01-09 16:10:41 UTC
Created attachment 62425 [details]
Currently used patch by Marcus.
Comment 17 Stefan Dirsch 2006-01-09 16:11:29 UTC
New xorg-x11 package with the patch applied above.