LD_LIBRARY_PATH is broken and should not be used if at all possible. It's broken because it overrides the search paths for all binaries that you run using it, not just the one that you care about, and it doesn't add easily to other competing settings of LD_LIBRARY_PATH. It has a tendency to cause odd breakage,
What is the purpose of inserting -L parameter if I have to specify additional variable with directory for searching for libraries?
with .a libraries it works fine. Why it doesn't work with .so libraries?
There are a few different ways to specify the library path for runtime. There are a few reasons to avoid using LD_LIBRARY_PATH, although it is the easiest solution when the shared object is not in the environments default library path. It may also be helpful if you want to switch between different versions of the same library.
Some alternatives (acquired via Google) include:
1. Provide an installation facility that places the shared object in /usr/lib.
2. Use parameter(s) to embed a specific path to find the shared object during linking. Note that an installation facility could be provided that does the linking and sets the appropriate path for the user.
3. Instruct the user to add an additional library path in /etc/ld.so.conf and run ldconfig.