desktop-packages team mailing list archive

[Bruno Nova <1181651@xxxxxxxxxxxxxxxxxx>]

The default GL option for x86_64 is mesa because bumblebee selects it during install, using update-alternatives.
But, for some reason, it doesn't do the same for i386.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvidia-graphics-drivers in Ubuntu.
https://bugs.launchpad.net/bugs/1181651

Title:
  ldconfig problem with 64-bit nvidia driver packages

Status in “nvidia-graphics-drivers” package in Ubuntu:
  Confirmed

Bug description:
  On Ubuntu 13.04 64-bit, the nvidia-319 package as well as other nvidia
  driver pakcages (including nvidia-current and nvidia-current-updates
  from the main ubuntu package repositories) don't play nice with
  applications that use 32-bit OpenGL libraries. When such an
  application tries to load the nvidia 32-bit libGL.so library, they
  don't load the nvidia libGL.so but some other non-nvidia libGL.so.
  This means a 32-bit application running on Ubuntu Raring 64-bit will
  never use the nvidia libGL.so library.

  After a lot of monkey business, I figured out what the problem is.
  Which libGL.so a 32-bit application uses on a 64-bit system is
  controlled by the file /etc/ld.so.conf.d/i386-linux-gnu_GL.conf which
  is just a symlink to /etc/alternatives/i386-linux-gnu_gl_conf which is
  another symlink to /usr/lib/nvidia-319/alt_ld.so.conf or something
  similar for other versions of the nvidia drivers. This file is blank
  in a clean install, so ldconfig doesn't know that 32-bit applications
  asking for libGL.so should get linked with the version in
  /usr/lib32/nvidia-319, so it links them with some other version. This
  breaks 32-bit programs like Steam (which throws a warning about not
  using direct rendering when it starts up) and 32-bit games like Team
  Fortress 2 (which fails to start altogether). Of course, this isn't
  specific to Steam and Team Fortress 2 but will affect any 32-bit
  program trying to use libGL.so and its associated libraries on a
  64-bit machine.

  fortunately, the fix for this is pretty simple: in the file
  /usr/lib/nvidia-319/alt_ld.so.conf in the nvidia-319 package add the
  lines:

  /usr/lib32/nvidia-319
  /usr/lib/nvidia-319

  This will tell ldconfig to use the nvidia libGL.so and associated
  libraries for 32-bit applications. For the other versions of the
  nvidia driver (such as nvidia-304 and nvidia-304-updates in the main
  ubuntu repositories) it's a simple matter of replacing nvidia-319 with
  nvidia-304, nvidia-304-updates, nvidia-313, etc. in the directory
  names.

  Although I reported this bug for the nvidia-319 package, I have
  checked and this bug applies at least to the nvidia-304 and
  nvidia-304-updates packages for Ubuntu 13.04 amd64 in the main ubuntu
  package repositories as well. It probably also applies to other nvidia
  driver packages as well, but I haven't checked those. I suppose all
  you'd have to look for is a blank /usr/lib/<nvidia driver package
  name>/alt_ld.so.conf file to check for the bug.

  The file I've included is the output of ldd (which prints the dynamic
  library dependencies of a program) when it's used on a 32-bit program
  that needs the 32-bit libGL.so on an Ubuntu 13.04 64-bit machine. In
  this case, the program I used ldd on is the 32-bit version of glxinfo
  from mesa-utils:i386. The nvidia driver version I had installed when I
  did this is nvidia-319. However, you will get a very similar result
  for other nvidia driver versions/packages.

  Also, I said "I don't know" for the package because 1.) it affects
  multiple packages and 2.) it didn't accept the package name
  nvidia-319.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1181651/+subscriptions