nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   libGL.so.1 "takes over" dynamic library loading (http://www.nvnews.net/vbulletin/showthread.php?t=131234)

polpo 04-07-09 07:21 PM

libGL.so.1 "takes over" dynamic library loading
1 Attachment(s)
It looks like the libGL.so.1 in version 180.44 somehow takes over dynamic library loading with dlopen. I first noticed it when trying to find out when a vendor package that the app I develop could not find one of its plugins. In the app that I develop, both our code and vendor code does a lot of loading of .so files with dlopen. We use RPATH to control the search path for these .so files so we don't have to worry about having LD_LIBRARY_PATH set at the app's runtime.

Here's the output from running the app with LD_DEBUG=all:

With Nvidia 180.44 libGL:

      9199:        file=liboaTclEngine.so [0];  needed by /usr/lib64/libGL.so.1 [0]
      9199:        find library=liboaTclEngine.so [0]; searching
      9199:        search path=/home/iscott/work/development/build64/pd/bin64/../lib64:/home/iscott/work/development/build64/pd/bin64/../vendor/lib64                (RPATH from file ../bin64/dfw)

Substituting in Mesa's libGL, using LD_PRELOAD:

      5011:        file=liboaTclEngine.so [0];  needed by /home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/liboaCommon.so [0]
      5011:        find library=liboaTclEngine.so [0]; searching
      5011:        search path=/home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/tls/x86_64:/home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/tls:/home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/x86_64:/home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg                (RUNPATH from file /home/iscott/work/development/build64/pd/vendor/lib64/linux_SuSE_64/dbg/../../../lib64/linux_SuSE_64/dbg/liboaCommon.so)

The code path that leads up to the library load that fails does not pass through any OpenGL code, but the main app and several support libs (such as libQtOpenGL) link against libGL.so.1.

This issue was not present in the previous version that I was using, 177.80. I'll try several different driver versions to see when this behavior started.

AaronP 04-07-09 11:12 PM

Re: libGL.so.1 "takes over" dynamic library loading
The driver does wrap dlopen, but it just calls down to the real dlopen with the same arguments so it shouldn't affect the search path. I'll forward your report to the right people.

AaronP 04-07-09 11:14 PM

Re: libGL.so.1 "takes over" dynamic library loading
Oh yeah, I forgot to mention that it would be very helpful if you could attach a test case that reproduces this problem.

polpo 04-07-09 11:50 PM

Re: libGL.so.1 "takes over" dynamic library loading
This behavior is present in all 180 and 185 version drivers, but is not in the 177 versions.

Thanks for the info. I'll work on a test case that can isolate this.

polpo 04-08-09 12:59 AM

Re: libGL.so.1 "takes over" dynamic library loading
1 Attachment(s)
A testcase is attached. It generates two executables, one that links against libGL, and one that doesn't. The executable calls a function inside liblib1.so, which then calls dlopen on liblib2.so, which is in a different directory. The different RPATHs on the main executable and the liblib1.so lets everything find what it needs.

177 program output:

iscott@iscott-laptop:~/work/dlopen-testcase> ./main-gl
Found liblib2.so.
iscott@iscott-laptop:~/work/dlopen-testcase> ./main-nogl
Found liblib2.so.

177 LD_DEBUG output:

      8520:        file=liblib2.so [0];  needed by /home/iscott/work/dlopen-testcase/liblib1.so [0]
      8520:        find library=liblib2.so [0]; searching
      8520:        search path=/home/iscott/work/dlopen-testcase/lib2/tls/x86_64:/home/iscott/work/dlopen-testcase/lib2/tls:/home/iscott/work/dlopen-testcase/lib2/x86_64:/home/iscott/work/dlopen-testcase/lib2                (RPATH from file /home/iscott/work/dlopen-testcase/liblib1.so)

180 program output:

iscott@iscott-laptop:~/work/dlopen-testcase> ./main-gl
Could not find liblib2.so.
iscott@iscott-laptop:~/work/dlopen-testcase> ./main-nogl
Found liblib2.so.

180 LD_DEBUG output:

    10413:        file=liblib2.so [0];  needed by /usr/lib64/libGL.so.1 [0]
    10413:        find library=liblib2.so [0]; searching
    10413:        search path=/home/iscott/work/dlopen-testcase                (RPATH from file ./main-gl)

If libGL is wrapping dlopen, that means that the RPATH of the library doing the dlopen call will be ignored, and instead the RPATH of the main executable is used. This presents a problem and I don't see any way around it aside from not wrapping dlopen.

sambo57u 04-09-09 01:48 PM

Re: libGL.so.1 "takes over" dynamic library loading
This is very interesting and may be the reason for our problem:

When I am running programs compiled with the intel compiler and logout of KDE
programs stop. I am running using nohup. When I run the same way other executables
or multi-threaded compilation using nohup they do not crash.

Intel has its libraries in a non-system location, which is in ld.so.conf file.

If I turn off logout effects in KDE 4.2.2 (fading etc.) it keeps running. Since these
effects use GL the above may be the problems.

All times are GMT -5. The time now is 07:24 PM.

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