Hi, the ebuilds for nvidia-glx install two versions of libnvidia-tls.so and opengl-update also links both versions to /usr/lib and /usr/lib/tls. Well, on non-NTPL systems, users may come across the error "cannot handle TLS data" since the newer TLS-version is loaded. On NPTL-enabled system, there is no such problem. So the nvidia-glx ebuild should install only one version of the libs: - the old TLS version on non-NTPL systems - the new TLS version on NPTL-enables systems You can also change opengl-update to only link one version of the libraries to /usr/lib, but for some some odd reason /etc/env.d/09opengl contains /usr/lib/opengl/nvidia/lib although opengl-update links the libraries there to /usr/lib. So opengl-update should be fixed first, so that only the desired version of the libnvidia-tls libraries is put into the ld-cache. At the moment, i can reproduce this only by using the java and loading libjogl.so. On non-NPTL systems it failes with the error "cannot handle TLS data" until i delete the files in /usr/lib/opengl/nvidia/tls. On NPTL-enabled system, there is no problem with both version of the libraries. Reproducible: Always Steps to Reproduce:
If you investigate futher, on ntpl enabled systems opengl-update will make the following link. andrew@asteroid /usr/lib $ ls /usr/lib/opengl/nvidia/lib/tls -l lrwxrwxrwx 1 root root 26 Sep 20 01:18 /usr/lib/opengl/nvidia/lib/tls -> /usr/lib/opengl/nvidia/tls Which then opengl-update will link /usr/lib/opengl/nvidia/lib/* (which includes the new tls link) to /usr/lib/* This was deliberately done so that the (first) link above is ONLY create IF AND ONLY IF ntpl is enabled on the system. ergo /usr/lib/tls should not exist on a non-ntpl system (unless you are using an broken version of opengl-update, please sync your tree and merge the newest 1.8.1 version of opengl-update, opengl-update nvidia and retest.) What you described as a bug was done deliberately so that the install was uniform across all systems, leaving it to opengl-update to only link ntpl enabled tls libraries if the sysm was ntpl enabled.
Hi, i took a look into the source of opengl-update, and your right: depending on a test, opengl-update installed both, or only the old version of libnvidia-tls.so, but the test is wrong it seems. I'm using a different program for determing the presence of NPTL, and i also tried the same command opengl-update uses. Both have different results: erni root # cat test.c #include <pthread.h> #include <stdio.h> #include <sys/types.h> #include <unistd.h> void *thread_routine(void *); void *thread_routine(void *arg) { printf("thread pid: %d\n", getpid()); return NULL; } int main(int argc, char *argv[]) { pthread_t tid; printf("main pid: %d\n", getpid()); pthread_create(&tid, NULL, thread_routine, NULL); pthread_join(tid, NULL); } erni root # gcc -l pthread -o test test.c erni root # ./test main pid: 12203 thread pid: 12205 erni root # /usr/lib/misc/tls_test /usr/lib/misc/tls_test_dso.so; echo $? 0 As you can see, pid and threadpid are different => i have no NPTL, but tls_test doesn't fail. I think opengl-update should use a different test than tls_test.
ayanami root # /usr/lib/misc/tls_test /usr/lib/misc/tls_test ayanami root # echo $? 1 ayanami root # /usr/lib/misc/tls_test /usr/lib/misc/tls_test_dso.so ayanami root # echo $? 0
@Travis: what does your comment #3 try to say? tls_test /usr/lib/misc/tls_test_dso.so is the command used by opengl-update-1.8.1-r1, and if i execute it on my both systems (one has NPTL, one doesn't), $? is 0 ! on both systems !
So here's the test-program again. It's modified, so the it's exit-value is 0 if NPTL is installed, and 1 if it isn't. #include <pthread.h> #include <stdio.h> #include <sys/types.h> #include <unistd.h> pid_t mpid; pid_t tpid; void *thread_routine(void *); void *thread_routine(void *arg) { tpid = getpid(); return NULL; } int main(int argc, char *argv[]) { pthread_t tid; pthread_create(&tid, NULL, thread_routine, NULL); pthread_join(tid, NULL); mpid = getpid(); printf("main pid: %d\n", mpid); printf("thread pid: %d\n", tpid); return mpid==tpid ? 0:1; }
oh, i just learned that the command getconf GNU_LIBPTHREAD_VERSION | grep -i nptl is a pretty good test for NPTL.
I'm waiting for a few responses from nvidia (in regards to quite a few things), but until such time im going to leave the status quo... This bug isn't about both being installed anymore, it is wether or not we are actually linking the ntpl enabled libs on the right type of glibc system.
I've tried editting opengl-update and replacing: /usr/lib/misc/tls_test /usr/lib/misc/tls_test_dso.so 2>/dev/null with: getconf GNU_LIBPTHREAD_VERSION | grep -i nptl 2>/dev/null Re-running "opengl-update nvidia" then fixes the problem nicely! Well done Sven! Andrew - knowing how longer nVidia take to reply to queries, is it worth releasing an interim ebuild that bodges opengl-update in the meantime? At least to get people's OpenGL programs working again?
I even got the "cannot handle TLS data" error while compiling libsdl on my non-NPTL system some days ago. I removed the TLS libs again, and everything was fine afterwards. Would be nice if there would be a fixed opengl-update. I think the tls_test binary (which provided by NVIDIA i think) is somewhat useless, althouhg i really don't know what's wrong with it. The command getconf GNU_LIBPTHREAD_VERSION | grep -i nptl seems to be a more reliable criteria whether to install TLS libraries or not. Well, it's not a test for a certain kind TLS-support, but every NPTL system should have the TLS support required by the NVidia drivers. It also seems that NPTL systems are the only ones that have the right kind of TLS support. Since people without NPTL have problems, the only conclusion i can draw is: fix opengl-update ;-) Thx Sven
Im dup'ing this to the newer bug, just so we dont have to track both. (please see the last comment I made there) *** This bug has been marked as a duplicate of 70545 ***
