View Single Post
Old 04-07-09, 08: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, 73 views)
polpo is offline   Reply With Quote