Since upgrading to this version, KDE and at least one other application (namely google-chrome) fail to load because they cannot find libnvidia-tls.so.304.48: $ LC_ALL=C startkde startkde: Starting up... Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kbuildsycoca4 running... kbuildsycoca4(5028) KBuildSycoca::checkTimestamps: checking file timestamps kbuildsycoca4(5028) KBuildSycoca::checkTimestamps: timestamps check ok kbuildsycoca4(5028) kdemain: Emitting notifyDatabaseChanged () kded(5027) Kded::loadModule: Could not load library "kded_powerdevil" . [ "Cannot load library /usr/lib64/kde4/kded_powerdevil.so: (libnvidia-tls.so.304.48: cannot open shared object file: No such file or directory)" ] QObject::connect: Cannot connect (null)::deviceFound(Device*) to BlueDevilDaemon::deviceFound(Device*) QObject::connect: Cannot connect QTimer::timeout() to (null)::stopDiscovery() kded(5027) Kded::loadModule: Could not load library "kded_keyboard" . [ "Cannot load library /usr/lib64/kde4/kded_keyboard.so: (libnvidia-tls.so.304.48: cannot open shared object file: No such file or directory)" ] QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kded(5027)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: Could not open library ksmserver: Cannot load library /usr/lib64/libkdeinit4_ksmserver.so: (libnvidia-tls.so.304.48: cannot open shared object file: No such file or directory) ksmserver: error while loading shared libraries: libnvidia-tls.so.304.48: cannot open shared object file: No such file or directory startkde: Shutting down... klauncher: Exiting on signal 1 startkde: Running shutdown scripts... startkde: Done. A working workaround is to LD_PRELOAD this library. This problem doesn't go away if I downgrade to 304.43, which used to work.
/etc/ld.so.conf is missing / at the beginning of /usr/lib64/OpenCL/vendors/nvidia /usr/lib32/OpenCL/vendors/nvidia /usr/lib64/opengl/nvidia/lib /usr/lib32/opengl/nvidia/lib Also, 32 was before 64. reordered and edited as above and running ldconfig solves the problem.
(In reply to comment #1) > /etc/ld.so.conf is missing / at the beginning of > > /usr/lib64/OpenCL/vendors/nvidia > /usr/lib32/OpenCL/vendors/nvidia > /usr/lib64/opengl/nvidia/lib > /usr/lib32/opengl/nvidia/lib > > Also, 32 was before 64. reordered and edited as above and running ldconfig > solves the problem. I should say "solves the immediate problem" -- I have no idea why ld.so.conf was borked nor how it should be "properly" addressed.
(In reply to comment #2) > (In reply to comment #1) > > /etc/ld.so.conf is missing / at the beginning of > > > > /usr/lib64/OpenCL/vendors/nvidia > > /usr/lib32/OpenCL/vendors/nvidia > > /usr/lib64/opengl/nvidia/lib > > /usr/lib32/opengl/nvidia/lib > > > > Also, 32 was before 64. reordered and edited as above and running ldconfig > > solves the problem. > > I should say "solves the immediate problem" -- I have no idea why ld.so.conf > was borked nor how it should be "properly" addressed. It's something deeper. chromium and virtualbox had failed to compile due to the same issue. I restarted emerge after the fix above and had to refix after both chromium and virtualbox as each time /etc/ld.so.conf was borked.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > /etc/ld.so.conf is missing / at the beginning of > > > > > > /usr/lib64/OpenCL/vendors/nvidia > > > /usr/lib32/OpenCL/vendors/nvidia > > > /usr/lib64/opengl/nvidia/lib > > > /usr/lib32/opengl/nvidia/lib > > > > > > Also, 32 was before 64. reordered and edited as above and running ldconfig > > > solves the problem. > > > > I should say "solves the immediate problem" -- I have no idea why ld.so.conf > > was borked nor how it should be "properly" addressed. > > It's something deeper. chromium and virtualbox had failed to compile due to > the same issue. I restarted emerge after the fix above and had to refix > after both chromium and virtualbox as each time /etc/ld.so.conf was borked. Last post, promise... /etc/env.d/03opencl and 03opengl are missing leading / in the LDPATH (ie LDPATH="usr/lib32/OpenCL/vendors/nvidia:usr/lib64/OpenCL/vendors/nvidia"). putting the leading / in resolves the repeated borking of /etc/ld.so.conf I assume until reemerging nvidia-drivers rebuilds the env file (assuming that's how it works)
This bug is pretty bad, rendered my system unusable as well. Solution was to downgrade to 304.43, fix /etc/env.d/03opencl and /etc/env.d/03opengl to have a leading slash in front of each element in LDPATH, fix /etc/ld.so.conf to reorder 64 before 32 and put leading slashes in and finally run ldconfig. Let's pull 304.48 off or put in a fix before it can do more damage to others :)
Same here, but doing eselect opengl set nvidia eselect opencl set nvidia solves the problem of startkde
(In reply to comment #6) > Same here, but doing > eselect opengl set nvidia > eselect opencl set nvidia > > solves the problem of startkde Same here, although ld.so.conf stays broken.
I confirm #6 comment: eselect opengl set nvidia eselect opencl set nvidia solves the problems (Virtualbox running, compiling etc), no manual editing of /etc files was needed
(In reply to comment #7) > Same here, although ld.so.conf stays broken. That was a mistake. Running eselect manually indeed fixes it. Even when I replicate exactly nvidia-driver's pkg_postinst() in a shell, it works. For some reason, it omits the leading slash when in the context of the ebuild, though. The problem disappears if I downgrade app-admin/eselect to 1.3.1 so it has to be introduced by some changes in app-admin/eselect-1.3.2.
I can confirm that emerge =eselect-1.3.1 emerge nvidia-drivers leaves /etc/env.d/03open[cg]l and /etc/ld.so.conf in the correct state with no additional work. Similarly after reupgrading to eselect-1.3.2 and reemerging nvidia-drivers, the env files are "incorrect" but eselect open[gc]l set nvidia also corrects the env files for me *now*. I swear I tried it yesterday but it didn't work. Still leaves 32bit first in order but perhaps that doesn't matter.
eselect-1.3.2 assigns EROOT=${ROOT%/}${EPREFIX} whereas 1.3.1 had EROOT=${ROOT}${EPREFIX}. With non-empty EPREFIX (which will always start with a /) this will remove a duplicate slash. With empty EPREFIX, it might remove a trailing slash in EROOT (which was never guaranteed to end with one, however).
Package masked eselect-1.3.2, for the time being: # Ulrich Müller <ulm@gentoo.org> (14 Sep 2012) # Exposes breakage in eselect-opengl. Masked until bug 434956 is sorted out. =app-admin/eselect-1.3.2
Adding eselect-opengl maintainer to CC.
I've investigated this further. The problem is in eselect-opengl and can be reproduced from within the shell. In the following, I'm always assuming the non-prefix case, i.e. EPREFIX="". $ ROOT="" eselect opengl set 1 This is working fine. $ ROOT=/ eselect opengl set 1 This causes the leading / to be missing in /etc/env.d/03opengl, as described in comment #4. The problem is in line 267 of opengl.eselect: ldpath="${ldpath:+${ldpath}:}${PREFIX#${ROOT}}/${libdir}/opengl/${gl_local}/lib" PREFIX is assigned to "${EROOT}/usr" before. Therefore, the assignment will be faulty with ROOT=/ and EROOT=${ROOT%/}${EPREFIX} (i.e., empty EROOT) which is the behaviour of eselect-1.3.2. Unfortunately, I cannot change the assignment in eselect to EROOT=${ROOT%/}${EPREFIX}/ (which is was Portage does) because that would expose another bug in e.g. line 51 of the opengl module: [[ ${ROOT} != / ]] && libdir=${libdir#${EROOT}} I've added a workaround for EROOT in eselect-1.3.2-r1 now. However, the eselect-opengl is very brittle and needs auditing, both on non-prefix and on prefix.
eselect-opengl is still broken in prefix. It still gives no leading / in ld.so.conf entries. Since the module assumes that ${PREFIX} is ${ROOT}${EPREFIX}/usr (which it currently is in the non-prefix case) one solution would be to actually set it to that, rather than to ${EROOT}/usr . Then ${PREFIX#{ROOT}} would give ${EPREFIX}/usr as expected. Another possibility would be to strip off ${ROOT%${EPREFIX:+/}} instead of ${ROOT}, since that is what eselect is currently prepending to ${EPREFIX} to get ${EROOT}, but this would break later if eselect changed to using portage's value.
