[CC to developers]
Trevor Wiens wrote:
I've finally decided to move to 6.0 from the 6.0 beta2. When compiling
I get a complaint about nviz with the suggestion to go the nviz
directory and execute make. Upon doing that I get the following error.
/usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2eea): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeQueryVersion'
/usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2f1a): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeGetModeLine'
Try to figure out why you don't have a shared libGL.
Recent Xorg versions of libGL depend upon libXxf86vm. If you had a
shared libGL (libGL.so), it would have dependency information which
would cause libXxf86vm to be linked automatically, e.g.:
$ ldd /usr/lib/libGL.so
libpthread.so.0 => /lib/libpthread.so.0 (0x40079000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x400cc000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x400d2000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x400e0000)
libdl.so.2 => /lib/libdl.so.2 (0x401a9000)
libc.so.6 => /lib/libc.so.6 (0x401ad000)
/lib/ld-linux.so.2 (0x80000000)
Static libraries don't include dependency information.
Note to developers: the libGL check in configure.in should probably be
updated to try using -lXxf86vm if the initial attempt fails.
--
Glynn Clements <glynn@gclements.plus.com>
Trevor Wiens wrote:
> Trevor Wiens wrote:
>
> > I've finally decided to move to 6.0 from the 6.0 beta2. When compiling
> > I get a complaint about nviz with the suggestion to go the nviz
> > directory and execute make. Upon doing that I get the following error.
> >
> > /usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2eea): In function `glXGetMscRateOML':
> > : undefined reference to `XF86VidModeQueryVersion'
> > /usr/X11R6/lib/libGL.a(glxcmds.o)(.text+0x2f1a): In function `glXGetMscRateOML':
> > : undefined reference to `XF86VidModeGetModeLine'
>
> Try to figure out why you don't have a shared libGL.
>
> Recent Xorg versions of libGL depend upon libXxf86vm. If you had a
> shared libGL (libGL.so), it would have dependency information which
> would cause libXxf86vm to be linked automatically, e.g.:
>
> $ ldd /usr/lib/libGL.so
> libpthread.so.0 => /lib/libpthread.so.0 (0x40079000)
> libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x400cc000)
> libXext.so.6 => /usr/lib/libXext.so.6 (0x400d2000)
> libX11.so.6 => /usr/lib/libX11.so.6 (0x400e0000)
> libdl.so.2 => /lib/libdl.so.2 (0x401a9000)
> libc.so.6 => /lib/libc.so.6 (0x401ad000)
> /lib/ld-linux.so.2 (0x80000000)
>
> Static libraries don't include dependency information.
>
> Note to developers: the libGL check in configure.in should probably be
> updated to try using -lXxf86vm if the initial attempt fails.
I have libGL.so (and family) in the following locations:
/usr/lib/debug/libGL.so.1
/usr/lib/debug/libGL.so.1.2
/usr/lib/libGL.so
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.0.7174
/usr/lib/nvidia/libGL.so.1.2.xlibmesa
/usr/lib/nvidia/libGL.so.1.xlibmesa
/usr/local/FWTools-linux-0.9.5/lib/Mesa/libGL.so
/usr/local/FWTools-linux-0.9.5/lib/Mesa/libGL.so.1
/usr/local/FWTools-linux-0.9.5/lib/Mesa/libGL.so.1.2.030402
/usr/local/openev/lib/Mesa/libGL.so
/usr/local/openev/lib/Mesa/libGL.so.1
/usr/local/openev/lib/Mesa/libGL.so.1.4.050002
/usr/local/openevsrc/Linux/lib/Mesa/libGL.so
/usr/local/openevsrc/Linux/lib/Mesa/libGL.so.1
/usr/local/openevsrc/Linux/lib/Mesa/libGL.so.1.4.050002
/usr/X11R6/lib/debug/libGL.so.1
/usr/X11R6/lib/debug/libGL.so.1.2
/usr/X11R6/lib/libGL.so
/usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa
/usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa
Now if I run ldd on either the libGL.so in /usr/X11R6/lib or /usr/lib I get the following.
> ldd /usr/lib/libGL.so
ldd: /usr/lib/libGL.so: No such file or directory
That suggests that /usr/lib/libGL.so is a symlink to a non-existent
file.
But if I run ldd on libGL.so.1 I get the following:
> ldd /usr/lib/libGL.so.1
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb7821000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb781f000)
libm.so.6 => /lib/tls/libm.so.6 (0xb77fc000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb77ef000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb772a000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7727000)
libc.so.6 => /lib/tls/libc.so.6 (0xb75f2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
I've got an nvidia card. Does this affect my library setup such that
I can't compile NVIZ properly? I found a binary version of GRASS 6.0
today and that works fine. So I guess I don't really need to resolve
the compile issue, but I'm curious and would like to figure out why
it didn't work, as I had problems with compiling NVIZ in the past
with earlier versions of GRASS.
nVidia supply their own libGL, which has some oddities, e.g. it may
not be compatible with the libGLU which is on the system. Also, it
often doesn't install correctly (e.g. you end up with headers which
don't match the libraries).
The first thing to try is fixing the symlink, e.g.:
ln -sf libGL.so.1 /usr/lib/libGL.so
Then, re-run configure and re-compile.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Jul 06, 2005 at 02:23:08PM +0100, Glynn Clements wrote:
Trevor Wiens wrote:
...
> I've got an nvidia card. Does this affect my library setup such that
> I can't compile NVIZ properly? I found a binary version of GRASS 6.0
> today and that works fine. So I guess I don't really need to resolve
> the compile issue, but I'm curious and would like to figure out why
> it didn't work, as I had problems with compiling NVIZ in the past
> with earlier versions of GRASS.
nVidia supply their own libGL, which has some oddities, e.g. it may
not be compatible with the libGLU which is on the system. Also, it
often doesn't install correctly (e.g. you end up with headers which
don't match the libraries).
The first thing to try is fixing the symlink, e.g.:
ln -sf libGL.so.1 /usr/lib/libGL.so
Then, re-run configure and re-compile.
I have a nVidia card as well.
Once 'glxgears' etc is working, GRASS will do as well.
Markus