cannot open shared object file: No such file or directory

ge1 · 07-01-2011, 06:50 AM

hi friends..

i have this shared object issue. it cannot get the libprint_test.so which is present in the same directory.

Code:

#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char *argv[])
{
void *handle;
void (*temp) (void);
char *error;

printf("entered into main\n");
handle = dlopen("libprint_test.so", RTLD_LAZY);
if(!handle)
{
fputs (dlerror(),stderr);
exit(1);
}
temp = dlsym(handle ,"temp");
if((error = dlerror()) != NULL)
{
fputs (error,stderr);
printf("cannot open the handle\n");
exit(1);
}
(*temp)();
dlclose(handle);
return 0;
}

so after writing this i did

Code:

testuser@testuser-desktop:~$ cd Documents/c_files/
testuser@testuser-desktop:~/Documents/c_files$ ls
a.out               findL.c          libprint_test.so   open_dll
atoi.c              findlist.c       ListHandle.txt     opendll.c
change_directory.c  find_List.c      listoffiles22.c    opendll.o
check_f_d.c         findLUn.c        list_with_count.c  open_dll.so
chg_f_d.c           itoa.c           main_chk.c         open_lib.c
chk_finL.c          libacl.so.1.1.0  my_folder          vinayteja.c
code_for_fin.c      libopendll.so    my_itoa.c
files_in_cwd.c      libopen_lib.so   opendll
testuser@testuser-desktop:~/Documents/c_files$ gcc opendll.c -ldl
testuser@testuser-desktop:~/Documents/c_files$ ./a.out 
entered into main
libprint_test.so: cannot open shared object file: No such file or directorytestuser@testuser-desktop:~/Documents/c_files$ export LD_LIBRARY_PATH=`pwd`
testuser@testuser-desktop:~/Documents/c_files$ ./a.out 
entered into main
/home/testuser/Documents/c_files/libprint_test.so: undefined symbol: tempcannot open the handle
testuser@testuser-desktop:~/Documents/c_files$

Questions.
1.i would like to ask why should we use export LD_LIBRARY_PATH.
2.why is that it is not detecting the libprint_test.so
3.i repeated the same test with with open_dll.so, its working fine, why?

Code:

testuser@testuser-desktop:~/Documents/c_files$ gcc opendll.c -ldl
testuser@testuser-desktop:~/Documents/c_files$ ./a.out 
entered into main
entered in to lib jzkgcvkzjvhkdjvhjk********

thank you for listening.
thanks a ton in advance for answering.

Skaperen · 07-01-2011, 08:11 AM

By default, when LD_LIBRARY_PATH is not set, dlopen() searches for simple names (those without a '/' character) in the libraries cached in the file /etc/ld.so.cache, as found by the "ldconfig" command (usually executed when libraries are changed by package updates). If LD_LIBRARY_PATH is set with one or more colon separated directory path names, those directories are searched earlier (as long as this executable is not flagged as setuid/setgid). See the man page for dlopen for the exact description.

If the file to be opened will always be in the current directory, you could change the code like this (delete the line prefixed by '-' and insert the line prefixed by '+'):

Code:

-handle = dlopen("libprint_test.so", RTLD_LAZY);
+handle = dlopen("./libprint_test.so", RTLD_LAZY);

and this would skip the search and just go straight to the specified file. A more permanent approach for an in-production program would be to place that .so file in a library directory and add it to the config(s) read by the "ldconfig" command (usually /etc/ld.so.conf and often separate files in /etc/ld.so.conf.d).

sundialsvcs · 07-01-2011, 08:39 AM

The first thing that I would do, either as root or via sudo, is to execute the ldconfig command.

Background: When a program requests the use of a library, the program can be as specific ("I want mylib.1.3.0") or as generic ("I want mylib," the latest version, please, as long as it's at least version 1") as it wishes to be. So, the first step in debugging is to determine which versions the program is actually requiring, and do qualifying versions actually exist. (The loader thinks that they don't.)

The next step is the loader-cache, hence "ldconfig." The loader constructs a cache-file to tell it exactly where the various libraries are located, so that it doesn't have to perform a filesystem search for each one. ldconfig reconstructs this cache. Although package installers usually re-execute this command for you, they might not. If the requested library is not in the cache, it won't be found, even if it exists in the file system.