1

I'm operating Ubuntu 20.04 on WSL2, and a little new to the bash syntax.

I overwrote the LD_LIBRARY_PATH when following a set of CUDA installation instructions, which specified to update as follows:

$ export LD_LIBRARY_PATH=/usr/local/cuda-11.5/lib64\
                         ${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

The value LD_LIBRARY_PATH now only contains the specified path /usr/local/cuda-11.5/lib64\ and no other paths, so I'm wondering if I accidentally overwrote the old path (because of the carriage return in the middle?) instead of appending to it.

There are two possibilities:

  1. The path was empty to start with, so nothing was overwritten, and no action required. This answer seems to indicate that it's originally empty, but running strings /etc/ld.so.cache as one of the comments suggest returns a long list.
  2. The path wasn't empty, in which case I'd like to restore it.
Sue Doh Nimh
  • 113
  • 5
  • 2
    Welcome to SO (well, SE!). Starting a new bash session should be good enough... let me explain a little bit more: running an export on bash only affects that bash session. So, if you start a new bash session, the variable will be set to the original value that it had. Only that specific bash where you ran the export is affected. – eftshift0 Nov 06 '21 at 03:21
  • 1
    BTW, breaking the command between lines like this will cause trouble. In this case, the old & new parts of the LD_LIBRARY_PATH must be directly adjacent, with no spaces or line breaks in between. In shell syntax, things like spaces are important delimiters, and adding or removing them can change the meaning of a command completely. – Gordon Davisson Nov 06 '21 at 04:39
  • @eftshift0 make that an answer and you'll get a +1 from me – Chris Davies Nov 06 '21 at 07:55
  • @gordondavisson make that an answer and you'll get a +1 from me – Chris Davies Nov 06 '21 at 07:55
  • Thank you both, very clear – Sue Doh Nimh Nov 06 '21 at 19:30

2 Answers2

4

The answer you're linking to is correct. As it says, ld uses a cache to keep track of installed libraries.

As the answer goes on to explain, LD_LIBRARY_PATH is empty by default and is only one part of how ld looks up libraries.

LD_LIBRARY_PATH is useful for situations such as when you need to override which library ld picks or if the library isn't even in the cache (e.g., if you're developing a shared library and haven't installed it and updated the cache). Also, as already mentioned in the comments, formatting of this environment variable matters and you should be careful not to introduce any unintended characters.

While a default installation doesn't set LD_LIBRARY_PATH, you may have set it in a shell startup script, and in that case you can either re-source the script (if you're overwriting and not amending the path) or simply start a new shell. If you're not doing anything with the variable by default, a simple unset LD_LIBRARY_PATH will do.

Lastly, there's no conflict between an empty LD_LIBRARY_PATH and non-empty return from strings /etc/ld.so.cache.

frippe
  • 355
1

You can get (most of the time) the original value of an environment variable on Linux with:

grep -z ^LD_LIBRARY_PATH= /proc/$$/environ | tr '\0' '\n'

Replace $$ with some other pid than the shell's and LD_LIBRARY_PATH with some other environment variable as needed.

The process could've of course just overwritten it; but both the ENVVAR=foo in the shell and setenv(3) in the C library are just allocating a new string somewhere else.

On a regular system, LD_LIBRARY_PATH is supposed to be empty, and only be set by wrapper scripts and similar.