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

Newegg Daily Deals

Reply
 
Thread Tools
Old 04-07-09, 07:21 PM   #1
polpo
Registered User
 
Join Date: Mar 2004
Posts: 8
Default libGL.so.1 "takes over" dynamic library loading

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:
Code:
      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:
Code:
      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.
Attached Files
File Type: gz nvidia-bug-report.log.gz (35.5 KB, 71 views)
polpo is offline   Reply With Quote
Old 04-07-09, 11:12 PM   #2
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default 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 is offline   Reply With Quote
Old 04-07-09, 11:14 PM   #3
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default 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.
AaronP is offline   Reply With Quote
Old 04-07-09, 11:50 PM   #4
polpo
Registered User
 
Join Date: Mar 2004
Posts: 8
Default 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 is offline   Reply With Quote
Old 04-08-09, 12:59 AM   #5
polpo
Registered User
 
Join Date: Mar 2004
Posts: 8
Default Re: libGL.so.1 "takes over" dynamic library loading

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:
Code:
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:
Code:
      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:
Code:
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:
Code:
     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.
Attached Files
File Type: gz dlopen-testcase.tar.gz (656 Bytes, 61 views)

Last edited by polpo; 04-08-09 at 02:01 PM. Reason: fix paths
polpo is offline   Reply With Quote
Old 04-09-09, 01:48 PM   #6
sambo57u
Registered User
 
Join Date: Jan 2006
Posts: 52
Default 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.
sambo57u is offline   Reply With Quote
Reply


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
X Failed to load NVdriver c00lr4c3r NVIDIA Linux 13 10-22-02 01:44 PM
Error messages... HELP!!!! Imperito NVIDIA Linux 3 09-24-02 10:46 PM
GForce drivers installed...but dont work tomfullery NVIDIA Linux 6 09-22-02 08:23 AM
Need help to get the X to work on my Acer TravelMate 630 knchee NVIDIA Linux 16 09-19-02 10:16 PM
RH7.3 and nForce - can't find the module dmw400 NVIDIA Linux 4 08-05-02 12:14 PM

All times are GMT -5. The time now is 06:44 PM.


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