On 6/2/2018 1:54 AM, Marc Glisse wrote:
On Fri, 1 Jun 2018, Edward Diener wrote:
An executable I am creating needs to link and run with a shared
library called, let's say, 'libmyshare.so' in a relative directory
called, let's say 'mylibs/lib'.
Does using the -L option while compiling the source files to object
files add the relative directory 'mylibs/lib' to the library search
path for shared libraries when linking ?
No. Since -L tells -l where to look, why would you want to separate them
into 2 separate commands? Did some documentation recommend that somewhere?
clang even gives you a warning if you pass -L to a compile (-c) command.
Do I specify the shared library to the linker as '-lmyshare' when
linking or do I rather specify the shared library simply as
'libmyshare.so' when linking ?
-lmyshare (or you can pass /full/path/to/libmyshare.so and omit the -L
option).
I have tried using '-Lmylibs/lib' when compiling and '-lmyshare' when
linking but the linker fails with the message:
/usr/bin/ld: cannot find -lmyshare
so I am doing something wrong and do not know what it is.
(your next question will likely be how to tell where to find the library
at runtime...)
My command line for the link is:
g++ -L./mylibs/lib -Wl,-rpath=./mylibs/lib -o myexec myobjectfile.o
-lmyshare
where:
ls -al ./mylibs/lib returns:
lrwxrwxrwx 1 root root 41 Jun 1 21:41 libmyshare.so ->
./mylibs/lib/libmyshare.so.1.0.0
lrwxrwxrwx 1 root root 41 Jun 1 21:41 libmyshare.so.1 ->
./mylibs/lib/libmyshare.so.1.0.0
-rw-r--r-- 1 root root 361660 Jun 1 10:33 libmyshare.so.1.0.0
and I still receive the message:
/usr/bin/ld: cannot find -lmyshare
Any ideas why ?
I had previously manually renamed the libmyshare.so.1.0.0 from the
original name it had after it was built. Could this be effecting the
linker finding the shared library ? Is the original name still embedded
somehow in the shared library file so that the linker sees only the
embedded original name for the shared library ? I can not think of any
other reason why the linker can not find -lmyshare.
