FS#9822 - [wxgtk, nvidia-utils] Can't build wxgtk when nvidia-utils installed

Attached to Project: Arch Linux
Opened by Rulatir (Rulatir) - Wednesday, 12 March 2008, 17:48 GMT
Last edited by Jan de Groot (JGC) - Sunday, 16 March 2008, 23:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I can't build wxgtk when nvidia-utils is installed. configure fails with:

checking for -lGL... no
checking for -lMesaGL... no
configure: error: OpenGL libraries not available

It seems that for some reason the configure process fails to recognize the GL library that comes with nvidia-utils as genuine libGL.so.

I know I should have removed nvidia drivers and tried with libgl (Mesa) just to see if it would work, but I was afraid of breaking my system, sorry.

Additional info:
* package version(s)

wxgtk-2.8.7-1
nvidia-utils-169.12-1

Steps to reproduce:

On a system with nvidia-utils installed:

$ yaourt -Sb wxgtk
This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 16 March 2008, 23:43 GMT
Reason for closing:  Works for me
Comment by Jan de Groot (JGC) - Thursday, 13 March 2008, 00:17 GMT
Is mesa installed on your system? And if so, what does the configure log tell you about this issue?
Comment by Rulatir (Rulatir) - Thursday, 13 March 2008, 15:20 GMT
Yes, mesa is installed, and quite a lot of things depend on it. Here's the snippet of configure log, starting at the first occurence of "GL":

checking for OpenGL headers... found in /usr/include
checking for GL/gl.h... yes
checking GL/glu.h usability... yes
checking GL/glu.h presence... yes
checking for GL/glu.h... yes
checking for -lGL... no
checking for -lMesaGL... no
configure: error: OpenGL libraries not available

/usr/lib/libGL.so is present on my system, however /usr/lib/libMesaGL.so is not. It is provided by libgl which in turn conflicts with nvidia-utils.

Comment by Rulatir (Rulatir) - Thursday, 13 March 2008, 15:26 GMT
> It is provided by libgl which in turn conflicts with nvidia-utils.

Actually it is not provided by libgl. I don't know what provides libMesaGL.so (mesa doesn't). Perhaps configure only checks for -lMesaGL when -lGL check fails. Why does it fail is the question.
Comment by Rulatir (Rulatir) - Thursday, 13 March 2008, 16:05 GMT
> It is provided by libgl which in turn conflicts with nvidia-utils.

Actually it is not provided by libgl. I don't know what provides libMesaGL.so (mesa doesn't). Perhaps configure only checks for -lMesaGL when -lGL check fails. Why does it fail is the question.
Comment by Jan de Groot (JGC) - Thursday, 13 March 2008, 16:16 GMT
You still haven't posted a config.log that shows the real error behind the user"friendly" errormessage.
Comment by Rulatir (Rulatir) - Thursday, 13 March 2008, 17:03 GMT
Sorry, I misunderstood your request, config.log is attached now.
   config.log (87.6 KiB)
Comment by Rulatir (Rulatir) - Thursday, 13 March 2008, 18:12 GMT

I added echos to the loop that chcecks for -lGL in configure. It appears that configure doesn't look in /usr/lib where the file is. It looks in /usr/lib64. Symlinking worked as a quick fix (libGLU.so needs a symlink too, and then configure doesn't check for -lMesaGL).

[later]

Perhaps the test at 2641 in configure.in is involved. It takes the lib64 path because /usr/lib64 is present on my system, containing openscenegraph. Should we blame openscenegraph for creating /usr/lib64 or patch our configure.in?

Comment by Jan de Groot (JGC) - Thursday, 13 March 2008, 20:38 GMT
How does the line look to check for -lGL? A forced /usr/lib64 check is actually a buggy check, but as a vanilla archlinux system doesn't have /usr/lib64, and as we're supposed to build from chroots or buildbots anyways, I don't consider this as a packaging bug.
Comment by Rulatir (Rulatir) - Friday, 14 March 2008, 01:39 GMT
The line is involved in constructing the list of paths where libraries are looked for. Granted, configure.in is the work of wx people. On top of that, my original assessment is clearly wrong: the issue has nothing to do with nvidia-utils and everything to do with /usr/lib64. Shame on me.

I am not sure we are building from chroot. Makepkg uses fakeroot which AFAIU only simulates some root user privileges and doesn't change root in the chroot sense; programs still see the normal filesystem.

To whom it may concern, if you are unlucky to have /usr/lib64, you can build wxgtk by symlinking libGL.so and libGLU.so from /usr/lib64 as described in comments above. I don't know how unsafe it is, or whether linked wxgtk applications will then require the symlinks.

Loading...