Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Thread Tools
Old 05-23-09, 12:06 PM   #1
Registered User
Join Date: Oct 2008
Posts: 12
Default Bug report for 185.18.10: probably broken 32-bit libGL.so


the following program demonstrates an issues I found while trying to run Wine on my Fedora 11 preview x86_64 machine:

#include <stdio.h>
#include <dlfcn.h>

#define RTLD_FIRST 0

int main(void)
#ifdef __LP64__
  const char *filename = "/usr/lib64/libGL.so.1";
  const char *filename = "/usr/lib/libGL.so.1";
  void *ret;
  int flag = 2;

  ret = dlopen( filename, flag | RTLD_FIRST );
  if (ret == NULL)
    printf("err %s\n", dlerror());
  return 0;
It results in this:
$ gcc -m64 -Wall -o testdl testdl.c -ldl
$ ./testdl 
$ gcc -m32 -Wall -o testdl testdl.c -ldl
$ ./testdl 
Segmentation fault
$ gdb  ./testdl
(gdb) run
warning: .dynamic section for "/lib/libm.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations

Program received signal SIGSEGV, Segmentation fault.
0x00c82307 in calloc () from /lib/libc.so.6
(gdb) where
#0  0x00c82307 in calloc () from /lib/libc.so.6
#1  0x01468889 in ?? () from /usr/lib/libGLcore.so.1
#2  0x00000001 in ?? ()
#3  0x00000034 in ?? ()
#4  0x0000000a in ?? ()
#5  0x00000002 in ?? ()
#6  0x0804bb10 in ?? ()
#7  0x0000029a in ?? ()
#8  0x0000564d in ?? ()
#9  0x00a652a2 in ?? () from /usr/lib/libGL.so.1
#10 0x0000029a in ?? ()
#11 0x0000564d in ?? ()
#12 0x01468800 in ?? () from /usr/lib/libGLcore.so.1
#13 0x0146882c in ?? () from /usr/lib/libGLcore.so.1
#14 0x0000564d in ?? ()
#15 0x01468800 in ?? () from /usr/lib/libGLcore.so.1
#16 0xffffd3e4 in ?? ()
#17 0x00a65861 in _init () from /usr/lib/libGL.so.1
#18 0x0000564d in ?? ()
#19 0x00000001 in ?? ()
#20 0x00000000 in ?? ()
If more information or further testing are needed, I'll be happy to help.

EDIT : One additional information: I compiled a random OpenGL program (RedBook aargb.c) with gcc -m32 and no explicit dlopen (that is libGL is loaded by ld.so) and unsurprisingly the problem is still there.

Can anyone reproduce the problem on some other x86_64 Linux distro?
Attached Files
File Type: gz nvidia-bug-report.log.gz (33.5 KB, 82 views)
ldesnogu is offline   Reply With Quote
Old 05-24-09, 05:46 AM   #2
Registered User
Join Date: Oct 2008
Posts: 12
Default Re: Bug report for 185.18.10: probably broken 32-bit libGL.so

I upgraded my FC11 preview x86_64 today and the problem disappeared (glibc was updated, I guess it was the culprit).

BTW when I uninstalled the drivers, the script pretended some of the libraries had been altered (wrong checksum). Is that something expected?
ldesnogu is offline   Reply With Quote
Old 05-25-09, 04:26 AM   #3
Registered User
Join Date: Feb 2005
Location: Paris, France
Posts: 129
Default Re: Bug report for 185.18.10: probably broken 32-bit libGL.so

dlopening libGL.so.1 is a rather annoying problem...

There is no real reason for anyone to dlopen a system library instead of linking to it !

Ok you have the lib64 over lib directory primary level hack, but on fedora-devel ml, they was a discussion about to move _prefix from /usr to / . What will you do if that move is picked ?(it isn't expected yet, but it should remain possible to change the default prefix).

Then, some packages provide replacement of libGL.so.1 in a sub-directory _libdir/nvidia, But it could be _libdir/nvidia-$serie-version or wherever. It will still be right since that's the system linker purpose to give the program the accurate version of the system libGL.so.1.
Everything that hardcode the expected path of such library will not be on the safe side. You can still remains in the dlopen world while requesting the linker the accurate libGL.so.1 AFAIK, but really, it is not on the safe side.

Not linking with -lGL will forbid that:
- You cannot use system linker and prelink the library to speed-up load time of your app.
- You will have to detect weird path at runtime for the correct libGL.so.1 according to the system/driver used. (instead of let this question to the system linker).
- Packaging of you apps (rpm/deb/other) will fail to retreive the dependencies at install time (optional library dependencies can still be filtered as needed).
- You can miss non-weak-symbol at runtime because of missing explicit library dependency.
- Everything that hardcode path over having a more portable solution is a bug by itself
(same for rpath, which fedora forbids one of the bad usage of rpath ).

One could say that linking with -lGL will make the library fail to load if every symbols aren't present at runtime. Hence it would be better to use dlopen...
But a more easier solution will be to use module linked with a given libGL vendor provider and then do dlopen the one that work. (like _libdir/your_app_modules/vendor_opengl3.so, _libdir/your_app_modules/mesa_opengl.so, etc).

But I would like to see what could be a nVidia developer guideline about this issue.

Last edited by kwizart; 05-25-09 at 04:41 AM. Reason: remove LD_LIBRARY_PATH, man dlopen seems to say it obbey anyway
kwizart is offline   Reply With Quote
Old 05-25-09, 06:33 AM   #4
Registered User
Join Date: Oct 2008
Posts: 12
Default Re: Bug report for 185.18.10: probably broken 32-bit libGL.so

Well it's not nVidia's problem in that case, you should direct your question to wine developers

Anyway that's a moot point given that even using -lGL did not solve the issue. As I wrote it probably was a glibc issue.
ldesnogu is offline   Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

All times are GMT -5. The time now is 03:43 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.