nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Bug report for 185.18.10: probably broken 32-bit libGL.so (http://www.nvnews.net/vbulletin/showthread.php?t=133406)

ldesnogu 05-23-09 12:06 PM

Bug report for 185.18.10: probably broken 32-bit libGL.so
1 Attachment(s)

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?

ldesnogu 05-24-09 05:46 AM

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?

kwizart 05-25-09 04:26 AM

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.

ldesnogu 05-25-09 06:33 AM

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.

All times are GMT -5. The time now is 12:13 AM.

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