Re: cannot open shared object file

The file '..../CRFPP.so' exists.

... but apparently not the file libcrfpp.so.0, which CRFPP.so seems to depend on. Without some more context, however, it's hard to tell what led to this problem, and how to solve it...

Update: a bit more background: shared libraries can be linked against other shared libraries (which in turn may even be linked against further shared libraries...). In this case, they depend on them, i.e. they are not self-contained. If any one of the those libs is not found, the toplevel .so file cannot be loaded, which is why the message begins with "Can't load '..../CRFPP.so' ...". Sometimes (as in this case — but not always), you'll find more detailed reasons, if you carefully read on.

Comment on Re: cannot open shared object file Select or Download Code

Replies are listed 'Best First'.
Re^2: cannot open shared object file by Anonymous Monk on Sep 26, 2007 at 14:00 UTC
I am sorry for being so 'rookie', but I just followed the instructions for making a perl binding for a c++ application (called crf++). Compilation was successful, except for some warning messages. The file 'libcrfpp.so.0' exists in /usr/local/lib (I added use lib "/usr/local/lib" to my script-don't know if this is correct) but the problem persists.	[reply]
Re^3: cannot open shared object file by almut (Canon) on Sep 26, 2007 at 14:39 UTC
I added `use lib "/usr/local/lib"` to my script This won't help here, as this only controls in which locations Perl will look for modules and their immediately related `.so` files. The secondary library dependencies have to be resolved/loaded by the system's dynamic linker (`ld-linux.so` on Linux), which has its own search path (LD_LIBRARY_PATH) and other facilities to control what to load from where and when (see `"man ld.so"` for details). In other words, as Sinistral suggested, one option would be to set/add `/usr/local/lib` to the LD_LIBRARY_PATH environment variable. A different option would be to link `CRFPP.so` statically against `libcrfpp`, but in this case you need the `.a` (archive) version of the library (which is probably available as well). See Re: Real Static Modules for how to achieve that when building the module yourself. In some cases this makes sense, in particular if you cater for easy deployment.	[reply] [d/l] [select]