How to add shared c library to the load path

In the “Calling C and Fortran Code” guide, it says you can add your shared library to the load path, but what exactly is this load path and which environmental variable does it correspond to? Is there a way to change this variable from Julia? The text I’m referring to is:

Shared libraries and functions are referenced by a tuple of the form (:function, "library") or ("function", "library") where function is the C-exported function name. library refers to the shared library name: shared libraries available in the (platform-specific) load path will be resolved by name, and if necessary a direct path may be specified.


If you’re on Linux, this should be the set of directories listed in the LD_LIBRARY_PATH environment variable. See for example the man page for ld.

I do not know the equivalent on other platforms (eg. MacOS or Windows).

1 Like

In linux it is LD_LIBRARY_PATH.

1 Like

For Windows it is the PATH environment variable.

Rather than messing with your library load path you are usually better off using the “direct path” option, similar to this example:

julia> const libc = "/lib/x86_64-linux-gnu/"

julia> ccall((:time, libc), Cint, ())
1 Like

This has the disadvantage of not being very portable, unless you specifically write a method to search for the library in a number of different paths

Not particularly. There are basically 3 cases to consider:

  1. The library is already in a standard load path. No problem to solve.

  2. The library is provided with or downloaded by your Julia code. Then you know its position relative to the file using it and can easily compute the direct path with the help of abspath and @__DIR__.

  3. The library is available in a non-standard location unrelated to the location of your Julia code. In this case you have to do something to inform Julia where it is. One option is to add it to the library load path. Another to set a separate environment variable that your Julia code reads to construct a direct path (environment variables are available in the ENV dict).

In case 2 there is no discussion that constructing a direct path is clearly better than modifying the library load path. If you look at packages wrapping external libraries, that’s what they do.

In case 3 it’s more of a draw. If there are other benefits of having it in the library load path, that’s obviously the way to go. If not it’s about the same complexity to set e.g. LD_LIBRARY_PATH as to set a custom environment variable. Except you might make a mistake when you set LD_LIBRARY_PATH and overwrite what was there before, which turned out to be something you also needed.