Probably due to changes in the Loader of X.Org 6.9/7.0 xorgcfg no longer works, i.e. it can't load any modules. I'm using the new ELF modules, which is default now. I'll attach a logfile.
Created attachment 4238 [details] Output of "xorgcfg -verbose 9 -verify"
Yep, dlopen() needs to resolve these symbols even with RTLD_LAZY or fail. Those symbols are normally provided by the server core.
xorgcfg should either a) be shot b) be hacked to load a broad set of modules before trying the video driver probe
> xorgcfg should either > a) be shot > b) be hacked to load a broad set of modules before trying the video driver probe Ajax, it's always easy to suggest to nuke something that doesn't work after somebody changed something else. In the long run we will be able to nuke xorgcfg - when we have a better on-the-fly mechanism. However for now we should try to fix it. Also b doesn't solve the problem as the unresolved symbols are implemented in the core server - not in the modules. Since xorgcfg isn't using the core server the symbols don't exist. I've been told that the problem really is a bug in the libdl loader - I'd have to investigate some more, though. What we could easily do is provide stubs for the missing symbols by using the macros on the dixsym.c misym.c xf86sym.c and extsym.c files. This would require small changes to the files - but may produce another nightmare for the build system.
(In reply to comment #4) > > xorgcfg should either > > > a) be shot > > b) be hacked to load a broad set of modules before trying the video driver probe > Ajax, it's always easy to suggest to nuke something that doesn't work after > somebody changed something else. a) was not a completely serious suggestion, correct. > Also b doesn't solve the problem as the unresolved symbols are implemented in > the core server - not in the modules. Since xorgcfg isn't using the core server > the symbols don't exist. good point, i had missed that. it sounds like providing stub symbols for these in xorgcfg is the right thing to do. > I've been told that the problem really is a bug in the libdl loader - I'd have > to investigate some more, though. > What we could easily do is provide stubs for the missing symbols by using the > macros on the dixsym.c misym.c xf86sym.c and extsym.c files. > This would require small changes to the files - but may produce another > nightmare for the build system. sounds reasonable to me.
I made a patch for the loader to introduce a new function called DoShowOptions. maybe xorgcfg could make use of it. The problem I have in checking the vendor and the option set for the drivers would be fixed with that patch. Simply call: X -showopts What do you think could this be checked in ? Thanks
Created attachment 4311 [details] [review] Xorg dif
Marcus, would you like to fix xorgcfg to use your new feature, too? This would greatly increase the chance of getting this fix integrated into X.Org. xorgcfg not have to load each and every module any more would be a huge win!
Marcus, were you thinking of making the changes mentioned in comment #8?
i'm wondering if i'm doing something wrong. i'm not able to reproduce this failure with xorgcfg on amd64.
Hm, I haven't tested this lately. Maybe the behavior the the dll loader has changed so it doesn't complain about the unresolved symbols any more. This surprises me as the undefined symbols it complained about all referenced data not code. Unresolved data symbols cannot be caught easily when referenced at run time - in contrast do code references.
(In reply to comment #11) > Hm, I haven't tested this lately. Maybe the behavior the the dll loader has > changed so it doesn't complain about the unresolved symbols any more. This > surprises me as the undefined symbols it complained about all referenced data > not code. Unresolved data symbols cannot be caught easily when referenced at run > time - in contrast do code references. indeed. (also, worksforme on x86 too. really not sure what's up with this one.)
Heh, can you reproduce it if you back out my changes to xorgcfg?
(In reply to comment #13) > Heh, can you reproduce it if you back out my changes to xorgcfg? i haven't tried, but it certainly looks plausible. do you happen to have the patch around somewhere?
cvs diff -D "2006-04-17" -D "2006-04-19" hw/xfree86/utils/ | patch -p0 -R There's one failure but should be easy to fix, it's just one of those XdotOrg tags.
(In reply to comment #15) > cvs diff -D "2006-04-17" -D "2006-04-19" hw/xfree86/utils/ | patch -p0 -R > > There's one failure but should be easy to fix, it's just one of those XdotOrg tags. So, even after backing this out, it still works. Hrm. Moving this to WFM. If anyone can reproduce it, please reopen.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.