Change current process environment's LD_LIBRARY_PATH

The reason

os.environ["LD_LIBRARY_PATH"] = ...

doesn't work is simple: this environment variable controls behavior of the dynamic loader (ld-linux.so.2 on Linux, ld.so.1 on Solaris), but the loader only looks at LD_LIBRARY_PATH once at process startup. Changing the value of LD_LIBRARY_PATH in the current process after that point has no effect (just as the answer to this question says).

You do have some options:

A. If you know that you are going to need xyz.so from /some/path, and control the execution of python script from the start, then simply set LD_LIBRARY_PATH to your liking (after checking that it is not already so set), and re-execute yourself. This is what Java does.

B. You can import /some/path/xyz.so via its absolute path before importing x.so. When you then import x.so, the loader will discover that it has already loaded xyz.so, and will use the already loaded module instead of searching for it again.

C. If you build x.so yourself, you can add -Wl,-rpath=/some/path to its link line, and then importing x.so will cause the loader to look for dependent modules in /some/path.

Based on the answer from Employed Russian, this is what works for me

oracle_libs = os.environ['ORACLE_HOME']+"/lib/"rerun = Trueif not 'LD_LIBRARY_PATH' in os.environ:  os.environ['LD_LIBRARY_PATH'] = ":"+oracle_libselif not oracle_libs in os.environ.get('LD_LIBRARY_PATH'):  os.environ['LD_LIBRARY_PATH'] += ":"+oracle_libselse:  rerun = Falseif rerun:  os.execve(os.path.realpath(__file__), sys.argv, os.environ)

In my experience trying to change the way the loader works for a running Python is very tricky; probably OS/version dependent; may not work. One work-around that might help in some circumstances is to launch a sub-process that changes the environment parameter using a shell script and then launch a new Python using the shell.