Re^2: cannot open shared object file

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.

Comment on Re^2: cannot open shared object file

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]