# Calling code from a library (.so): works on one system, fails on another

**URL:** https://discourse.julialang.org/t/calling-code-from-a-library-so-works-on-one-system-fails-on-another/904
**Category:** General Usage
**Created:** [December 12, 2016, 10:32pm UTC](https://discourse.julialang.org/t/calling-code-from-a-library-so-works-on-one-system-fails-on-another/904 "2016-12-12T22:32:45Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![m-j-w](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/m-j-w/32/4541_2.png) [@m-j-w](https://discourse.julialang.org/u/m-j-w)
#### Post date: [December 13, 2016, 1:03am UTC](https://discourse.julialang.org/t/calling-code-from-a-library-so-works-on-one-system-fails-on-another/904/3 "2016-12-13T01:03:53Z")

</div>

Dynamically linked libraries may depend on other dynamic libraries. The dependencies are resolved by the dynamic linker when the library is loaded, and the internal function pointers in the library are replaced to point to the correct function in the target library. However, such a dependency might not be resolved if the target library is not found, but an error would typically only then be raised if in fact a function is called that depends on such other libraries.

This seems to be happening in your case.

One way to tell the dynamic linker where to find other libraries is the environment variable `LD_LIBRARY_PATH`, which is essentially the counter-part to the executable search path `PATH`.

To check which other libraries your library depends on, type

```
ldd /path/to/my_lib1.so

```

in the shell. This should give at least one line with an unresolved dependency. You may also check the same command from within the Julia REPL. Type exactly the same, but prepend a semicolon `;` to enter the shell mode.

An example would be for libopenblas with all other libraries being correctly resolved:

```julia
ldd /usr/lib/libopenblas.so.0
	linux-vdso.so.1 => (0x00007ffcb52ca000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd472e24000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd472c06000)
	libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fd4728d5000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd47250e000)
	/lib64/ld-linux-x86-64.so.2 (0x00005590dab09000)
	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fd4722ce000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd4720b5000)

```

Then simply locate the missing library manually (e.g. by typing `locate my_lib2`) and set the `LD_LIBRARY_PATH` prior to starting Julia. And don’t forget the `export` when using `bash`. This can also be done with just one line, prepending the environment variable to be set for said command, viz.

```
LD_LIBRARY_PATH=/path/to/my_lib julia

```

How to best resolve this issue permanently depends on your specific case, and how and by whom those libraries were built.

---

_[View the full topic](https://discourse.julialang.org/t/calling-code-from-a-library-so-works-on-one-system-fails-on-another/904)._