| |
Michael Marklew wrote:
> However,
> I can not get the demo lnptest to run. I get
>
> ./lnptest: error in loading shared libraries: liblnp.so.0: cannot open shared
> object file: No such file or directory
>
> I checked the makefile and it points to ../liblnp which is where the complied
> library is.
Well, it's mentioned in the README ;-), but obviously not detailed
enough.
The problem is: the dynamic loader doesn't find the library you linked
against. The dynamic loader is a program that is started whenever you
execute a dynamically linked program, and makes sure the dynamic
libraries used by your program are mapped into memory. By default, the
dynamic loader looks for dynamic libs in some standard places, which are
listed in file /etc/ld.so.conf. However, the dynamic loader doesn't scan
this directories (this might take far too long), instead it get's the
needed information from binary file /etc/ld.so.cache.
So, the option a sysadmin would take:
copy liblnp.so.0.0.1 into one of the directories listed in
/etc/ld.so.conf, perhaps /usr/local/lib, and (as root) run
/sbin/ldconfig. This will scan the directories listed in ld.so.conf,
update the cache file, and create a symbolic link from liblnp.so.0.0.1
to liblnp.so.0. The link is created, because the actual name of the
library stored in the library itself, the so called soname, is
liblnp.so.0. This is also the name stored in your program during
compilation.
If you don't want to touch system files, this is the safe user way:
If you set Environment Variable LD_LIBRARY_PATH to a colon separated
list of paths ( like PATH ), the dynamic loader will scan all
directories in this list for dynamic libraries. This is the way i use
this mechanism: i have a lib diectory under my HOME, where i put all my
self-made dynamical libs, and set LD_LIBRARY_PATH in my HOME/.bashrc to
this directory. Recall, the dynamic loader looks for the soname, what is
liblnp.so.0. So i follow the common trend to copy liblnp.so.0.0.1 to
~/lib, and create a symbolic link from liblnp.so.0.0.1 to liblnp.so.0.
However, you could also just rename it.
The third option is to link partly statically, which means, system libs
are linked dynamically, but the linking of liblnp ist static. You
arrange this by simply removing the shared libs, (actually you only have
to remove the symbolic link liblnp.so), before making lnptest.c. In this
case, the linker sees no dynamic library and falls back to static
linking against liblnp.a. If you never plan to use several different
programs linked against liblnp simultanously, this maybe the way to go.
BTW, you can test which dynamic libs are used/found to run <program> by:
$> ldd <program>
hope that doesn't confuse you even more, Martin
|
|
Message has 1 Reply:
 | | Re: LNP Example please
|
| *Embarrased look* sorry I shouldn't of missed that.. Sorry to hassle you but I am stuck yet again. The lnptest program just records collision after collision. I have no other IR devices in the area (as far as I know anyway) It doesn't display any of (...) (25 years ago, 12-Feb-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: LNP Example please
|
| Just updated my libc version (I love apt-get on debian linux... woohoo... it took about 30 seconds to update about 6 core applications on my system with a single simple command !!) Ok. it now complies without a problem and lnp also appears to run (...) (25 years ago, 10-Feb-00, to lugnet.robotics.rcx.legos)
|
21 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
