[GRASS-user] configure no longer finds opengl

Seb · October 7, 2007, 2:58pm

Hi,

I've been successfully building cvs grass for a few months in a AMD64
Debian unstable system. However, I now run into a configure error, even
though my *dev packages haven't changed. The particular error is:

,-----[ tail /usr/local/src/grass-cvs/config_log.txt ]
| checking whether to use OpenGL... yes
| checking for location of OpenGL includes... /usr/include/GL
| checking for GL/gl.h... yes
| checking for GL/glu.h... yes
| checking for location of OpenGL library... /usr/lib64
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| configure: error: *** Unable to locate OpenGL library.
`-----

and I've given --with-opengl-libs=/usr/lib and
--with-opengl-includes=/usr/include/GL. I can see /usr/lib/libGL.so.1,
although there's also /usr/lib64/libGL.so.1, and they're both a symlink to
/usr/lib/libGL.so.100.14.19. Any help would be appreciated.

Cheers,

--
Seb

Brad_Douglas · October 7, 2007, 7:09pm

On Sun, 2007-10-07 at 09:58 -0500, Seb wrote:

Hi,

I've been successfully building cvs grass for a few months in a AMD64
Debian unstable system. However, I now run into a configure error, even
though my *dev packages haven't changed. The particular error is:

,-----[ tail /usr/local/src/grass-cvs/config_log.txt ]
| checking whether to use OpenGL... yes
| checking for location of OpenGL includes... /usr/include/GL
| checking for GL/gl.h... yes
| checking for GL/glu.h... yes
| checking for location of OpenGL library... /usr/lib64
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| checking for glBegin in -lGL... no
| configure: error: *** Unable to locate OpenGL library.
`-----

and I've given --with-opengl-libs=/usr/lib and
--with-opengl-includes=/usr/include/GL. I can see /usr/lib/libGL.so.1,
although there's also /usr/lib64/libGL.so.1, and they're both a symlink to
/usr/lib/libGL.so.100.14.19. Any help would be appreciated.

I gave you several suggestions last night in IRC, but you didn't seem to
follow up on them.

We really can't help you unless you post the relevant section of
config.log, detailing the error. Otherwise, we're guessing as much as
you are.

AFAIK, there have been no changes relating to OGL in quite some time.

--
73, de Brad KB8UYR/6 <rez touchofmadness com>

Seb · October 7, 2007, 8:42pm

On Sun, 07 Oct 2007 19:09:12 +0000,
Brad Douglas <rez@touchofmadness.com> wrote:

[...]

I gave you several suggestions last night in IRC, but you didn't seem to
follow up on them.

I did follow up on one of them, I didn't think the other one was the
problem because I said I've had the same development packages as before
(including the opengl libraries) so why would it become a problem all of a
sudden? I'm asking again here to post the question to a broader audience,
so I don't understand why the acrymonious message.

We really can't help you unless you post the relevant section of
config.log, detailing the error.

The only relevant lines in the config log were the ones I posted, so I
don't understand what you mean.

--
Seb

Glynn_Clements1 · October 7, 2007, 9:00pm

Seb wrote:

> We really can't help you unless you post the relevant section of
> config.log, detailing the error.

The only relevant lines in the config log were the ones I posted, so I
don't understand what you mean.

You don't appear to have posted anything from config.log. Your
previous post says:

,-----[ tail /usr/local/src/grass-cvs/config_log.txt ]

The config.log file is called config.log, not config_log.txt.

As Brad says, we can't help you without seeing the relevant portion of
config.log.

BTW: OpenGL includes are in /usr/include, not /usr/include/GL. The
leading GL/ is part of the header name, so you need to specify the
directory containing the GL subdirectory. But /usr/include is searched
automatically, so there's no need to specify it (on some systems,
doing so can break compilation).

--
Glynn Clements <glynn@gclements.plus.com>

Seb · October 7, 2007, 9:29pm

On Sun, 7 Oct 2007 22:00:05 +0100,
Glynn Clements <glynn@gclements.plus.com> wrote:

[...]

The config.log file is called config.log, not config_log.txt.

Ok, my config_log.txt is a log of the messages received during configure.
It's harder for me to understand the config.log, but here is what I think
are the relevant lines:

,-----[ tail -n 70 /usr/local/src/grass-cvs/config.log ]
| ; return 0; }
| configure:10878: checking whether to use SQLite
| configure:11108: checking whether to use FFMPEG
| configure:11345: checking whether to use OpenGL
| configure:11379: checking for location of OpenGL includes
| configure:11405: checking for GL/gl.h
| configure:11413: gcc -E -I/usr/include/GL conftest.c >/dev/null 2>conftest.out
| configure:11405: checking for GL/glu.h
| configure:11413: gcc -E -I/usr/include/GL conftest.c >/dev/null 2>conftest.out
| configure:11447: checking for location of OpenGL library
| configure:11476: checking for glBegin in -lGL
| configure:11493: gcc -o conftest -g -Wall -L/usr/lib64 -Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm 1>&5
| /usr/bin/ld: cannot find -lGL
| collect2: ld returned 1 exit status
| configure: failed program was:
| #line 11482 "configure"
| #include "confdefs.h"
| /* Override any gcc2 internal prototype to avoid an error. */
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char glBegin();
|
| int main() {
| glBegin()
| ; return 0; }
| configure:11512: checking for glBegin in -lGL
| configure:11529: gcc -o conftest -g -Wall -L/usr/lib64 -Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm -lXext 1>&5
| /usr/bin/ld: cannot find -lGL
| collect2: ld returned 1 exit status
| configure: failed program was:
| #line 11518 "configure"
| #include "confdefs.h"
| /* Override any gcc2 internal prototype to avoid an error. */
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char glBegin();
|
| int main() {
| glBegin()
| ; return 0; }
| configure:11548: checking for glBegin in -lGL
| configure:11565: gcc -o conftest -g -Wall -L/usr/lib64 -Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm -lpthread 1>&5
| /usr/bin/ld: cannot find -lGL
| collect2: ld returned 1 exit status
| configure: failed program was:
| #line 11554 "configure"
| #include "confdefs.h"
| /* Override any gcc2 internal prototype to avoid an error. */
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char glBegin();
|
| int main() {
| glBegin()
| ; return 0; }
| configure:11584: checking for glBegin in -lGL
| configure:11601: gcc -o conftest -g -Wall -L/usr/lib64 -Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm -lpthread -lXext 1>&5
| /usr/bin/ld: cannot find -lGL
| collect2: ld returned 1 exit status
| configure: failed program was:
| #line 11590 "configure"
| #include "confdefs.h"
| /* Override any gcc2 internal prototype to avoid an error. */
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char glBegin();
|
| int main() {
| glBegin()
| ; return 0; }
`-----

My exact call to configure is:

CFLAGS="-g -Wall" ./configure --enable-64bit --with-libs=/usr/lib64 \
--with-tcltk-includes=/usr/include/tcl8.4 --with-readline --with-cxx \
--with-odbc --with-mysql --with-mysql-includes=/usr/include/mysql \
--with-postgres --with-postgres-includes=/usr/include/postgresql \
--with-proj-share=/usr/share/proj --with-motif \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
2>&1 | tee config_log.txt

As Brad says, we can't help you without seeing the relevant portion of
config.log.

BTW: OpenGL includes are in /usr/include, not /usr/include/GL. The
leading GL/ is part of the header name, so you need to specify the
directory containing the GL subdirectory. But /usr/include is searched
automatically, so there's no need to specify it (on some systems, doing
so can break compilation).

I tried both with and without specifying it, but that didn't seem to make
a difference. Thanks.

--
Seb

Glynn_Clements1 · October 7, 2007, 11:42pm

Seb wrote:

> The config.log file is called config.log, not config_log.txt.

Ok, my config_log.txt is a log of the messages received during configure.
It's harder for me to understand the config.log, but here is what I think
are the relevant lines:

Yep, those are the ones.

| configure:11476: checking for glBegin in -lGL
| configure:11493: gcc -o conftest -g -Wall -L/usr/lib64 -Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm 1>&5
| /usr/bin/ld: cannot find -lGL

I was assuming that it was going to be more involved than that;
failure to detect a library is often due to missing dependencies
(rather than the library itself).

Somewhere on your system should be a library named e.g. libGL.so.1.2.
There should also be a symlink to this file, named libGL.so.

Going back to your original message:

I can see /usr/lib/libGL.so.1, although there's also
/usr/lib64/libGL.so.1, and they're both a symlink to
/usr/lib/libGL.so.100.14.19. Any help would be appreciated.

you don't mention the libGL.so symlink, so I would guess that it's
missing. This symlink is needed for compilation, but not at run time.

The unversioned .so symlinks are normally included in the development
package (e.g. "opengl-devel") along with the headers. If you already
have the headers, the missing symlink may to be due to a botched
package management operation.

[A Google search on libGL.so.100.14.19 suggests that this is nVidia's
proprietary OpenGL library. nVidia's OpenGL packaging leaves a lot to
be desired.]

In any case, it should suffice to just add the symlink, manually e.g.:

ln -s libGL.so.1 /usr/lib64/libGL.so

--
Glynn Clements <glynn@gclements.plus.com>

Seb · October 8, 2007, 12:57am

On Mon, 8 Oct 2007 00:42:46 +0100,
Glynn Clements <glynn@gclements.plus.com> wrote:

[...]

I was assuming that it was going to be more involved than that; failure
to detect a library is often due to missing dependencies (rather than
the library itself).

Somewhere on your system should be a library named e.g. libGL.so.1.2.
There should also be a symlink to this file, named libGL.so.

Going back to your original message:

I can see /usr/lib/libGL.so.1, although there's also
/usr/lib64/libGL.so.1, and they're both a symlink to
/usr/lib/libGL.so.100.14.19. Any help would be appreciated.

you don't mention the libGL.so symlink, so I would guess that it's
missing. This symlink is needed for compilation, but not at run time.

The unversioned .so symlinks are normally included in the development
package (e.g. "opengl-devel") along with the headers. If you already
have the headers, the missing symlink may to be due to a botched package
management operation.

[A Google search on libGL.so.100.14.19 suggests that this is nVidia's
proprietary OpenGL library. nVidia's OpenGL packaging leaves a lot to be
desired.]

In any case, it should suffice to just add the symlink, manually e.g.:

ln -s libGL.so.1 /usr/lib64/libGL.so

Thanks Glynn, this is very helpful and I can now investigate this further.
Debian unstable recently upgraded to a new Xorg version, and NVIDIA's
drivers followed suit, but the latter must have broken/removed the
libGL.so symlink (yes, it's missing here). The error creeped in after
updating these Xorg/NVIDIA packages.

Thanks again for your help,

--
Seb

H_B · October 8, 2007, 1:45am

Seb wrote:
> | configure:11476: checking for glBegin in -lGL
> | configure:11493: gcc -o conftest -g -Wall -L/usr/lib64
-Wl,--export-dynamic -L/usr/lib64 conftest.c -lGL -lSM -lICE -lX11 -lm
1>&5
> | /usr/bin/ld: cannot find -lGL

Glynn:

I was assuming that it was going to be more involved than that;
failure to detect a library is often due to missing dependencies
(rather than the library itself).

Somewhere on your system should be a library named e.g. libGL.so.1.2.
There should also be a symlink to this file, named libGL.so.

Is the libgl1-mesa-dev package installed? It provides that.

In general you can check the control file in DebianGIS SVN to see what packages
are needed to build GRASS with the latest Debian/unstable:
http://svn.debian.org/wsvn/pkg-grass/packages/grass/trunk/debian/?rev=0&sc=0

The rules file is good to get a working ./configure line.

apt-file is a nice Debian tool for finding which pacakge(s) contains the
missing library. If multiple packages are listed for the same file, you can
expect they will conflict with each other.

#the following is for Etch not unstable!
$ apt-file search libGL.so
fglrx-driver: usr/lib/libGL.so.1
fglrx-driver: usr/lib/libGL.so.1.2
libgl1-mesa-dev: usr/lib/libGL.so
libgl1-mesa-glide3: usr/lib/i686/mmx/cmov/libGL.so.1
libgl1-mesa-glide3: usr/lib/i686/mmx/cmov/libGL.so.1.5.060201
libgl1-mesa-glide3: usr/lib/libGL.so.1
libgl1-mesa-glide3: usr/lib/libGL.so.1.5.060201
libgl1-mesa-glide3-dev: usr/lib/i686/mmx/cmov/libGL.so
libgl1-mesa-glide3-dev: usr/lib/libGL.so
libgl1-mesa-glx: usr/lib/libGL.so.1
libgl1-mesa-glx: usr/lib/libGL.so.1.2
libgl1-mesa-swx11: usr/lib/i686/cmov/libGL.so.1
libgl1-mesa-swx11: usr/lib/i686/cmov/libGL.so.1.5.060501
libgl1-mesa-swx11: usr/lib/libGL.so.1
libgl1-mesa-swx11: usr/lib/libGL.so.1.5.060501
libgl1-mesa-swx11-dbg: usr/lib/debug/i686/cmov/libGL.so
libgl1-mesa-swx11-dbg: usr/lib/debug/i686/cmov/libGL.so.1
libgl1-mesa-swx11-dbg: usr/lib/debug/i686/cmov/libGL.so.1.5.060501
libgl1-mesa-swx11-dbg: usr/lib/debug/libGL.so
libgl1-mesa-swx11-dbg: usr/lib/debug/libGL.so.1
libgl1-mesa-swx11-dbg: usr/lib/debug/libGL.so.1.5.060501
libgl1-mesa-swx11-dev: usr/lib/i686/cmov/libGL.so
libgl1-mesa-swx11-dev: usr/lib/libGL.so
lsb-build-base2: usr/lib/lsb2/libGL.so
lsb-build-base3: usr/lib/lsb3/libGL.so
nvidia-glx: usr/lib/libGL.so.1
nvidia-glx: usr/lib/libGL.so.1.0.8776
nvidia-glx-legacy: usr/lib/libGL.so.1
nvidia-glx-legacy: usr/lib/libGL.so.1.0.7184
nvidia-glx-legacy-dev: usr/lib/libGL.so

Going back to your original message:

> I can see /usr/lib/libGL.so.1, although there's also
> /usr/lib64/libGL.so.1, and they're both a symlink to
> /usr/lib/libGL.so.100.14.19. Any help would be appreciated.

you don't mention the libGL.so symlink, so I would guess that it's
missing. This symlink is needed for compilation, but not at run time.

The unversioned .so symlinks are normally included in the development
package (e.g. "opengl-devel") along with the headers. If you already
have the headers, the missing symlink may to be due to a botched
package management operation.

[A Google search on libGL.so.100.14.19 suggests that this is nVidia's
proprietary OpenGL library. nVidia's OpenGL packaging leaves a lot to
be desired.]

In any case, it should suffice to just add the symlink, manually e.g.:

ln -s libGL.so.1 /usr/lib64/libGL.so

Those tricks are almost never needed in Debian, you just have to install the
correct packages & then things work. e.g. I first installed Debian on my busy
development machine in Jan 2004 and still have not needed to add /usr/local/lib
to /etc/ld.so.conf or symlink to any library version. Actually, with Debian, I
have found using those tricks or trying to be smarter than the packagers
usually backfires.

Hamish

____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/

Seb · October 8, 2007, 2:06am

On Sun, 7 Oct 2007 18:45:32 -0700 (PDT),
Hamish <hamish_nospam@yahoo.com> wrote:

[...]

Is the libgl1-mesa-dev package installed? It provides that.

Yes, it's installed, but I see something strange occurring. I'm aware of
apt-file (I love it!), but found that it only installed the following
files (checking through synaptic):

-rw-r--r-- 1 root root 22k Aug 9 12:08 /usr/share/doc/libgl1-mesa-dev/copyright
-rw-r--r-- 1 root root 14k Aug 28 05:11 /usr/share/doc/libgl1-mesa-dev/changelog.Debian.gz

despite apt-file telling me that libgl1-mesa-dev provides libGL.so for
unstable. I can only guess that nvidia-glx might have manipulated this,
and given libGL.so.1 only instead.

In general you can check the control file in DebianGIS SVN to see what
packages are needed to build GRASS with the latest Debian/unstable:
http://svn.debian.org/wsvn/pkg-grass/packages/grass/trunk/debian/?rev=0&sc=0

Thank you, I wish I knew about this before!

--
Seb

H_B · October 8, 2007, 6:38am

Hamish wrote:
> Is the libgl1-mesa-dev package installed? It provides that.

Seb wrote:

Yes, it's installed, but I see something strange occurring. I'm aware
of apt-file (I love it!), but found that it only installed the following
files (checking through synaptic):

..

despite apt-file telling me that libgl1-mesa-dev provides libGL.so for
unstable.

what do these show:

$ dpkg -L libgl1-mesa-dev
$ locate libGL.so
$ ls -l /usr/lib/libGL.so

I can only guess that nvidia-glx might have manipulated this, and given
libGL.so.1 only instead.

AFAIK one debian package Will Not play tricks with another package's
files. No two packages can contain the same file without conflicting with
each other.

> In general you can check the control file in DebianGIS SVN to see what

..

Thank you, I wish I knew about this before!

see also the DebianGIS wiki:
http://wiki.debian.org/DebianGis

Hamish

Seb · October 8, 2007, 1:57pm

On Mon, 8 Oct 2007 19:38:10 +1300,
Hamish <hamish_nospam@yahoo.com> wrote:

[...]

what do these show:

$ dpkg -L libgl1-mesa-dev

and then:

,-----[ ls -al /usr/lib/nvidia ]
| total 3980
| drwxr-xr-x 2 root root 4096 2007-09-30 06:13 .
| drwxr-xr-x 202 root root 81920 2007-10-07 23:05 ..
| -rw-r--r-- 1 root root 2523994 2007-09-29 16:13 libGLcore.so.xlibmesa
| -rw-r--r-- 1 root root 513928 2007-08-28 09:00 libGL.so.1.2.xlibmesa
| lrwxrwxrwx 1 root root 12 2007-08-28 20:19 libGL.so.1.xlibmesa -> libGL.so.1.2
| -rw-r--r-- 1 root root 542394 2007-09-29 16:13 libglx.so.xlibmesa
| -rw-r--r-- 1 root root 127480 2007-09-22 19:22 libnvidia-cfg.so.100.14.19
| -rw-r--r-- 1 root root 3408 2007-09-22 19:22 libnvidia-tls.so.100.14.19
| -rw-r--r-- 1 root root 222010 2007-09-29 16:13 libwfb.so.xserver-xorg-core
| -rwxr-xr-x 1 root root 5064 2007-09-22 19:22 tls_test
| -rw-r--r-- 1 root root 4920 2007-09-22 19:22 tls_test_dso.so
`-----

... no libGL.so.xlibmesa nor libGL.so.1.2 (it's a broken symlink)!! It
looks like nvidia-glx did mess up with libgl1-mesa-dev and introduced a
bug. Do you agree?

Doing what Glynn suggested (adding the link myself), let configure go
ahead without errors, and compilation proceeded similarly. I'm with you
though in that I prefer to leave everything under /usr (and others) up to
Debian (I know about backfires from my own manipulations there!).

Thanks everybody for your help with this,

--
Seb