Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find, -lGL
Do you have nvidia-glx installed? That package diverts some files in the xlibmesa-gl package, which leads to the dangling symlink /usr/lib/libGL.so. Here's what dpkg -L xlibmesa-gl prints for me: /. /usr /usr/X11R6 /usr/X11R6/lib /usr/X11R6/lib/libGL.so.1.2 diverted by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa /usr/share /usr/share/doc /usr/share/doc/xlibmesa-gl /usr/share/doc/xlibmesa-gl/copyright /usr/share/doc/xlibmesa-gl/NEWS.Debian.gz /usr/share/doc/xlibmesa-gl/changelog.Debian.gz /usr/lib /usr/X11R6/lib/libGL.so.1 diverted by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa /usr/lib/libGL.so.1 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa /usr/lib/libGL.so.1.2 diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa And nvidia-glx does not contain the file /usr/lib/libGL.so.1.2, so the symlink /usr/lib/libGL.so in the xlibmesa-gl-dev package points nowhere. :-( This issue is long known, see http://bugs.debian.org/208198 for details. It became finally fixed in version 1.0.7667-2 of nvidia-glx, which is in experimental. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find, -lGL
I have nvidia-glx and nvidia-glx-dev installed from experimental, because unstable has rather old packages. I use nvidia-glx 1.0.7676-1. [[Background info about my OpenGL development: I experiment with OpenGL 2.0 and GL SL, and would like to use nVidia extensions in a controlled manner (optional, if nVidia HW is present). So I need to switch back and forth between standard OpenGL headers and nVidia provided headers. I have seen that Mesa supports OpenGL 2.0 as well, at least GL_SHADING_LANGUAGE_VERSION is defined which I need for the 3DLabs OpenGL 2.0 only examples. ]] I have read bug report #208198 and am somewhat confused. It has become a combinatorical problem, and my head smokes. But there seems to be an easy way out: libGL.so.1 is linked to different files whether Mesa or nVidia libs are used: libGL.so.1 - libGL.so.1.2 (Mesa SW only driver) or libGL.so.1 - libGL.so.1.0.7676 (nVidia 76.76 driver) You create a symlink: libGL.so - libGL.so.1.2 which assumes too much. Either it is diverted as well, which adds complexity for every new driver, or: Simply change the symlink to ,, libGL.so - libGL.so.1 ^^ This works for both Mesa and nVidia without complex and error prone scripting. I do not know if ldconfig optimizes such symlink chains, but I think startup time is not hampered too much by that. If it were, I would rather file a bug against ldconfig to add optimization there, because having variants is not confined to OpenGL, but result of competition. This would be a great step towards allowing the new nVidia driver to enter unstable. Several versions since 71.74 have not entered unstable yet, although they seem to work. I think the bug #208198 and some automatic nVidia chip detection for the newer drivers which do not support older HW are still missing. Andre Heynatz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find, -lGL
Processing commands for [EMAIL PROTECTED]: severity 332753 important Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find -lGL Severity set to `important'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find, -lGL
severity 332753 important thanks Andre Heynatz wrote: I have read bug report #208198 and am somewhat confused. It has become a combinatorical problem, and my head smokes. But there seems to be an easy way out: libGL.so.1 is linked to different files whether Mesa or nVidia libs are used: libGL.so.1 - libGL.so.1.2 (Mesa SW only driver) or libGL.so.1 - libGL.so.1.0.7676 (nVidia 76.76 driver) You create a symlink: libGL.so - libGL.so.1.2 which assumes too much. Either it is diverted as well, which adds complexity for every new driver, or: Simply change the symlink to ,, libGL.so - libGL.so.1 ^^ This works for both Mesa and nVidia without complex and error prone scripting. I do not know if ldconfig optimizes such symlink chains, but I think startup time is not hampered too much by that. If it were, I would rather file a bug against ldconfig to add optimization there, because having variants is not confined to OpenGL, but result of competition. Seems logical to me, but I'm definitely no expert in such things. Maintainers, what do you think? Meanwhile, I've downgraded the severity of the bug to important, because it only affects users of nvidia-glx. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find -lGL
Package: xlibmesa-gl-dev Version: 6.8.2.dfsg.1-8 Severity: grave Tags: patch Justification: renders package unusable I tried to compile lesson02 from the NeHe OpenGL Tutorial (SDL GLX variant): $ make gcc -Wall -ansi lesson02.c -o lesson02 `sdl-config --cflags --libs` -lGL -lGLU /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status Looking closer at the problem: gcc -Wall -ansi lesson02.c -o lesson02 -Wl,--verbose `sdl-config --cflags --libs` -lGL -lGLU attempt to open /usr/lib/libGL.so failed attempt to open /usr/lib/libGL.a failed attempt to open /usr/lib/gcc/i486-linux-gnu/4.0.2/libGL.so failed attempt to open /usr/lib/gcc/i486-linux-gnu/4.0.2/libGL.a failed attempt to open /usr/lib/gcc/i486-linux-gnu/4.0.2/libGL.so failed attempt to open /usr/lib/gcc/i486-linux-gnu/4.0.2/libGL.a failed d attempt to open /usr/lib/gcc/i4/usr/bin/ld: cannot find -lGL GNU ld obviously expects from a shared object that a filename ending with '.so' is provided, without version information. Often, this is a symlink. Here is what I have done to fix the problem: $ su # cd /usr/lib # ln -s libGL.so.1 libGL.so # ldconfig It should be possible to compile OpenGL programs out of the box, even if the patch above is simple. Andre Heynatz -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xlibmesa-gl-dev depends on: ii libc6-dev [libc-dev] 2.3.5-6GNU C Library: Development Librari ii libx11-dev6.8.2.dfsg.1-8 X Window System protocol client li ii libxext-dev 6.8.2.dfsg.1-8 X Window System miscellaneous exte ii x-dev 6.8.2.dfsg.1-8 X protocol development files ii xlibmesa-gl 6.8.2.dfsg.1-8 Mesa 3D graphics library [X.Org] xlibmesa-gl-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
