Bug 5502

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.