0

I want to use an additional library when compiling an application but I am not able to add the path to the library directory to LD_LIBRARY_PATH hence it's not found by the build system:

I added the path to the library directory /etc/ld.so.conf.d, in a new file petsc.conf which contains /home/klaus/OpenFOAM/klaus-5.0/petsc-3.7.6/arch-linux2-c-debug/lib

and when I run ldconfig -p the library IS found but it doesn't appear in the LD_LIBRARY_PATH

I also added the path to .bashrc

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/klaus/OpenFOAM/klaus-5.0/petsc-3.7.6/arch-linux2-c-debug/lib

sourced it, later rebooted but when I check LD_LIBRARY_PATH with

env | grep '^LD_LIBRARY_PATH'

the library is still not included and I get a compile error that it's not found (linked)

What needs to be done on top of these steps to add a library to LD_LIBRARY_PATH?

vasek
  • 2,759
  • 1
  • 26
  • 30
Klausb
  • 83
  • 4

2 Answers2

2

LD_LIBRARY_PATH doesn't affect linking. LD_LIBRARY_PATH is used at load time to override default library search paths. You should use full path to your library (like g++ -l/path/to/mylib/lib_mylib.so ...) or provide search path (like g++ -L/path/to/mylib/)

At run time, use LD_LIBRARY_PATH or link with -rpath option (to add non default library search path at link time).

ivaigult
  • 6,198
  • 5
  • 38
  • 66
0

Assume I am using libfunc.so in a file names temp.c

man 3 dlopen:

       dlclose, dlopen, dlmopen - open and close a shared object

SYNOPSIS
       #include <dlfcn.h>

       void *dlopen(const char *filename, int flags);

       int dlclose(void *handle);

       #define _GNU_SOURCE
       #include <dlfcn.h>

       void *dlmopen (Lmid_t lmid, const char *filename, int flags);

       Link with -ldl.

first way to use dynamic library (= directly tell the linker):

ALP ❱ gcc temp.c -ldl
ALP ❱ ./a.out
libfunc.so: cannot open shared object file: No such file or directory
ALP ❱ pwd
/home/shu/codeblock/ALP
ALP ❱ gcc temp.c -ldl -Wl,-rpath,/home/shu/codeblock/ALP
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2

second way to use dynamic library (= using environment variable LD_LIBRARY_PATH):

ALP ❱ export LD_LIBRARY_PATH=$PWD
ALP ❱ echo $LD_LIBRARY_PATH
/home/shu/codeblock/ALP
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2
ALP ❱ export LD_LIBRARY_PATH=
ALP ❱ ./a.out
libfunc.so: cannot open shared object file: No such file or directory

third way to use dynamic library (= copy it to a standard path):

ALP $ sudo cp libfunc.so /usr/lib
ALP ❱ gcc temp.c -ldl
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2

NOTE

how to find that a path is in your a.out file
first compile it and use strings and grep:

ALP ❱ gcc temp.c -ldl -Wl,-rpath,/home/shu/codeblock/ALP
ALP ❱ strings a.out  | grep \/
/lib/ld-linux.so.2
/home/shu/codeblock/ALP

have been tested on Ubuntu 16.04 LTS

Shakiba Moshiri
  • 21,040
  • 2
  • 34
  • 44
  • Nothing of this is being asked, and `sudo cp libfunc.so /usr/lib`? Huh? Don't touch your system directories. – n. m. could be an AI Oct 05 '17 at 11:40
  • I'm not talking about rights, I'm talking about sensible behaviour. You have a right to wreck your system sure. And of course you don't have much rights on a system which isn't yours. – n. m. could be an AI Oct 05 '17 at 14:57
  • Since you have a higher score than me let yourself to tell me that. Eventually a shared object goes to a standard path and of course standard path is for this like other files that are there. – Shakiba Moshiri Oct 05 '17 at 15:02
  • If you build a Linux distro, you decide what goes in /usr/lib. Otherwise, nope, your libraries most definitely don't go to /usr/lib. – n. m. could be an AI Oct 05 '17 at 15:12
  • **First** `cp` a `lib` for test has no problem **never** since it can be `rm -f` later. **Second** my answer is prefect then the other ones and I just let the user/OP choose one of them; it is even better that one as marked duplicated. Anyway thank you for letting me know you better. – Shakiba Moshiri Oct 05 '17 at 15:20
  • I have no desire to continue this fruitless exchange. I have downvoted and explained what's wrong, I've done my part. – n. m. could be an AI Oct 05 '17 at 15:37
  • Likewise me. I told you before; when you down-voted me for an undefined behavior in a `C++` code. Instead of being so strict to others, you could be friendly and modify my answer and make it better if you see any problems. The only thing that I did not mention is **warning/telling** to `rm` after doiing `cp`. I know/remember your answer already. You do not want to modify/edit others question. have a nice day. – Shakiba Moshiri Oct 05 '17 at 16:10
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/156032/discussion-between-n-m-and-k-five). – n. m. could be an AI Oct 05 '17 at 16:57