From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: When running this sample program with the latest binary nVidia drivers (1.0.4349) dlopen eventually bails with this... Opening libGL, try 0 Opening libGL, try 1 Opening libGL, try 2 Error: /usr/lib/tls/libGL.so: shared object cannot be dlopen()ed: static TLS memory too small Segmentation fault Use this sample program... ----- #include <dlfcn.h> main() { void *lib; int i; for (i = 0 ; i < 10 ; i++) { printf("Opening libGL, try %d\n",i); lib = dlopen("/usr/lib/tls/libGL.so", RTLD_LAZY); if (!lib) printf("Error: %s\n",dlerror()); dlclose(lib); } } Version-Release number of selected component (if applicable): glibc-2.3.2-27.9 How reproducible: Always Steps to Reproduce: 1.Use the sample program attached in the description 2. 3. Additional info:
I've checked in a patch in the official glibc CVS archive. The change will be in the next build. Please try it. I don't use that proprietary code so I cannot check that specific case myself.
Where do I get it ? I'm using rhn - when will it appear there ?
Bug still present (in some form) in glibc-2.3.2-71. I have RH9 + updates + latest rawhide (via apt). Using nvidia's latest drivers I have a similar problem: ---XFree86 log (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so dlopen: /usr/X11R6/lib/modules/extensions/libglx.so: cannot allocate memory in static TLS block --- Using Alan's test case program already mentioned above, I can reproduce the problem: --- [martin@earth tmp]$ ./glibctest Opening libGL, try 0 Error: /usr/lib/tls/libGL.so: cannot allocate memory in static TLS block Segmentation fault (core dumped) --- Is there a workaround? That would be awesome so I could use opengl (no games right now). It would be also cool to get this fixed without having to downgrade off of the rawhide glibc. If this won't be fixed for a while and there is no workaround that's what I'll have to do (shudder).
Works for me. rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc glibc-2.3.2-71.i686 unless you have LD_ASSUME_KERNEL= <= 2.4.19 in the environment. Either use NPTL and TLS libGL, or use linuxthreads and non-TLS libGL.
Interesting. Definitely doesn't work for me with your version of glibc and my custom kernel: --- 'uname -r' = "2.4.21smp-lowlat-pre-dvd" [martin@earth tmp]$ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc glibc-2.3.2-71.i686 --- But I found a workaround: If I define LD_ASSUME_KERNEL=2.4.21, it works! It appears with that defined, the linker chooses /lib/tls/libc.so.6 and /lib/tls/libm.so.6, which work. Otherwise, /lib/i686/libc.so.6 and /lib/i686/libm.so.6 are used, which *don't* work. I have run ldconfig as root multiple times. I can attach the output of 'ldconfig -v' in case it helps. Any pointers you can give to help me understand why is this happening are appreciated.
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks.