Richard Rauch <rauch@eecs.ukans.edu> writes:

> What I did, and what appears to work, is to install XFree86 v4.0 (or
> later, one presumes), and then build (but not install)
> Mesa-glx. 

Ok, what I have going now is a pre-xpkgwedge Mesa (not -glx)
installed, such that /usr/X11R6/lib contains:

-rwxr-xr-x   1 root  wheel      711 Apr 12 15:53 libGL.la
lrwxr-xr-x   1 root  wheel       12 Apr 12 15:53 libGL.so.3 -> libGL.so.3.0
-rwxr-xr-x   1 root  wheel  1951697 Apr 12 15:53 libGL.so.3.0
-rw-r--r--   1 root  wheel   182330 Apr 12 15:53 libGLU.a
-rwxr-xr-x   1 root  wheel      683 Apr 12 15:53 libGLU.la
lrwxr-xr-x   1 root  wheel       13 Apr 12 15:53 libGLU.so -> libGLU.so.3.0
lrwxr-xr-x   1 root  wheel       13 Apr 12 15:53 libGLU.so.3 -> libGLU.so.3.0
-rwxr-xr-x   1 root  wheel   170626 Apr 12 15:53 libGLU.so.3.0
-rw-r--r--   1 root  wheel   351348 Apr 12 15:53 libglut.a
-rwxr-xr-x   1 root  wheel      728 Apr 12 15:53 libglut.la
lrwxr-xr-x   1 root  wheel       15 Apr 12 15:53 libglut.so -> libglut.so.10.0
lrwxr-xr-x   1 root  wheel       15 Apr 12 15:53 libglut.so.10 -> libglut.so.10.0
-rwxr-xr-x   1 root  wheel   290044 Apr 12 15:53 libglut.so.10.0

I have installed XFree86's CVS from the other day over top
of that so now I have also

-rw-r--r--   1 root  wheel   429968 Aug 12 00:05 libGL.a
lrwxr-xr-x   1 root  wheel       12 Aug 12 00:05 libGL.so -> libGL.so.1.2
lrwxr-xr-x   1 root  wheel       12 Aug 12 00:05 libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x   1 root  wheel   364272 Aug 12 00:05 libGL.so.1.2

Note where libGL.so.1 points.

Also, of course, Mesa's includes and so forth under
/usr/X11R6/include were overwritten by the XFree86 installation.

I just did "make update" in pkgsrc/x11/xlockmore, and see:

/usr/pkg/bin/xlock:
         -lc.12 => /usr/lib/libc.so.12
         -lICE.6 => /usr/X11R6/lib/libICE.so.6
         -lSM.6 => /usr/X11R6/lib/libSM.so.6
         -lXpm.4 => /usr/X11R6/lib/libXpm.so.4
         -lGL.1 => /usr/X11R6/lib/libGL.so.1
         -lGLU.3 => /usr/X11R6/lib/libGLU.so.3
         -laudiofile.0 => /usr/pkg/lib/libaudiofile.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lossaudio.0 => /usr/lib/libossaudio.so.0
         -lesd.2 => /usr/pkg/lib/libesd.so.2
         -lcrypt.0 => /usr/lib/libcrypt.so.0
         -lX11.6 => /usr/X11R6/lib/libX11.so.6
         -lXext.6 => /usr/X11R6/lib/libXext.so.6
         -lstdc++.2 => /usr/lib/libstdc++.so.2

which is using libGL from XFree86 and libGLU from Mesa.

"xlock -nolock -mode gears" works OK.

Likewise, pkgsrc/games/battalion rebuilds happily and ends
up with:

/usr/pkg/bin/battalion:
         -lc.12 => /usr/lib/libc.so.12
         -lGL.1 => /usr/X11R6/lib/libGL.so.1
         -lGLU.3 => /usr/X11R6/lib/libGLU.so.3
         -lm.0 => /usr/lib/libm.so.0
         -lX11.6 => /usr/X11R6/lib/libX11.so.6
         -lXext.6 => /usr/X11R6/lib/libXext.so.6

and runs fine [**].

I imagine that if I were xpkgwedge-less, I could install a
new Mesa or Mesa-glx and then reinstall XFree86's libGL
shared objects and includes, and new programs would DTRT.

Alternatively, Mesa/Mesa-glx could be made aware of
XFree86's more recent libGL stuff, and leave it alone.

I get lost thinking about how this would work with
xpkgwedge installed. -:)   Is that why you had to tweak
library & include locations?  It "just worked" for me.

        Sean.

P.S.: [**] 

  Battalion continues to display the improper shading when in
  highest-quality mode.  (I first noticed this, I think, after doing a
  massive package rebuild around May.)  Wireframe mode in Battalion is also
  broken (about the same time-frame, too).

Yes, I observe this too.  The wireframe mode is not
"broken" for me -- it behaves as the highest-quality mode
should behave if it were working (i.e., the wireframes are
shaded in.  I think the server is doing the filling in,
because when I try to run the battalion X client on an X
server without the GLX extension, it complains "No glx
extension!\ncould not open a window" and exits.)