> > > You can get rid of this error by copying /usr/X11R6/lib/X11/xdm/libXdm* 
> > > to /usr/X11R6/lib , but that likely still won't solve the problem (it didn'
> > t 
> > > for me... :-( )
> > 
> > Uh, copying those files there actually even "gets rid of" that error?
> 
> I'm pretty sure it did... (I believe a "ktrace xdm" indicated that it couldn't
> open the file, and so I suspected ld.elf_so wasn't looking in the right place 
> for it..  I played a bit with setting LD_LIBRARY_PATH to 
> /usr/lib:/usr/X11R6/lib, and when xdm still gave the error, I copied the 
> files, at which point it didn't complain any more.)

Could you try this again, and send me the ktrace output, etc.?

The reason why i'm so hard to convince in this case is that i'm
running the same binaries you are (i think! 8-), and in mine the code
was broken in such a way that the dlopen() call which was to load
"/usr/X11R6/lib/X11/xdm/libXdmGreet.so" would never proceed to the
point where anything would try to open that file...

By virtue of the fact that the file is specified with a full path
name, the dynamic loader should (and does, with binaries fixed so that
it is actually invoked properly, as far as I can tell) load it using
that exact path and ignore the search path.


> > I hope to have the complete solution (and the binaries with the
> > problem fixed up for FTP 8-) by tomorrow evening.
> 
> Sounds good :-)  

Actually, it looks like the second half of this problem may in fact be
a "known" linker bug.  (I was warned about the presence of such a bug
by Richard Henderson at the end of January, but had never run into it
myself.  He did warn me that it was "subtle" though. 8-) If so, I may
not have a 'simple' fix by tomorrow, though in that case i could put
up an XDM which doesn't load the greeter library dynamically.



chris