Since this is a 1.5_ALPHA question, I guess this mailing list is
appropriate.  (^& (tech-x11 might also do for the main thrust...) (Also, I
read the mailing lists via web-page in general.  There is sometimes
several days' latency, so please include me in the CC list of replies.)

The context: I did a binary install of XFree86 v4.0 on a 1.5_ALPHA (i386)
machine.  I had hoped to minimize any problems by using the binary files
for NetBSD 1.4-current.  Unfortunately, during install it tried to use
ldconfig (which failed; I don't remember the exact error message that
scrolled by).

The problem: It cannot now find the desired .so files.

The new XFree86 binary _is_ an ELF binary, though.  (As I understood it,
ldconfig was deprecated with the transition to ELF.)  Short of waiting for
XFree86.org to fix it, or for NetBSD to integrate 4.0-or-later (or
reverting to 3.3.6 (^&), what options are available to me?

(FWIW: Running ``XFree86 -configure'' works, save that it isn't bright
enough to find the wsmouse.  It is when I run ``startx'' (after fixing the
config file and moving it to the new /etc/X11) that things fail.
Configuring was done as root (yes, horrors), and the attempt to _use_ X
was done with my normal user account.)

I remember that there was an environment variable that was discussed for
controlling ELF .so lookup.  Would that cause me grief later?  If not,
what is the variable?  Would it ``just work'' if I rebuilt from the 4.0
sources?  (Perhaps with some hacking of compiler options?)  Even though
there is no ldconfig binary, it seems that the NetBSD 1.5_ALPHA sources
still include the sources to ldconfig---should I consider building
ldconfig?

Or is there a painless way to bulk-twiddle the binaries to get them all to
know the proper location?  (I remember some discussion about this feature
as well.)


(While I'm posting anyway, a loosely related question: I have some OpenGL
type code.  When rebuilding under NetBSD 1.5_ALPHA, I had to not only have
``-L<dir>'' but also ``-Wl,-R<dir>''.  ...well, I assumed that I needed to
keep ``-L<dir>''.  (^& Is there a way to avoid this redundancy of
specifying library directories twice?)


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu