I am trying to run under opensuse 12.1 the folowing executable
(here is the output from file:
sessmgr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped)

and I always get the following error message :

sessmgr: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

I have set LD_ASSUME_KERNEL=2.2.5

The strange thing is that libcrypt.so.1 exists and all locations are set properly in LD_LIBRARY_PATH

Any good ideas appreciated

Best regards
Christos Michail

my e-mail is crmichail@gmail.com

Welcome to LQ.

May be your OS is 64bits ? The command : 'uname -m' will show.

Thank you for your answer
uname -m says i686

and all executables on /bin /sbin /usr/bin are reported as 32 bit

Christos

Well, then please try : 'ldd sessmgr'

"sessmgr" could be an old file requiring a glibc object "2.2.5"
not present in the Suse 12.1 "glibc-2.14.1" files.
( libcrypt.so.1 is part of glibc-2.14.1 ).

.

Thanks again for the reply

Here is the output of ldd -v sessmgr

linux-gate.so.1 => (0xffffe000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb76e5000)
libtermcap.so.2 => /usr/lib/libtermcap.so.2 (0xb76e0000)
libc.so.6 => /lib/libc.so.6 (0xb7573000)
/lib/ld-linux.so.2 (0xb7734000)

Version information:
./sessmgr:
libcrypt.so.1 (GLIBC_2.0) => /lib/libcrypt.so.1
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libcrypt.so.1:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/usr/lib/libtermcap.so.2:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

Best regards from Athens
Christos

can you supply more information for it:

1) env | grep LD_LIBRARY_PATH

2) ls -l /lib/libcrypt.so.1 (it is a demo, use correct libcrypt.so.1 location instead).

: )

Thank you very much for replying Buddy
Here is the information you requested

==================================================================================================== ==
## LD_ASSUME_KERNEL=2.4.7
LD_ASSUME_KERNEL=2.2.5
## LD_ASSUME_KERNEL=2.4.20
## LD_ASSUME_KERNEL=2.4.1
## LD_ASSUME_KERNEL=2.6.8
## LD_ASSUME_KERNEL=2.6.16
## LD_ASSUME_KERNEL=
export LD_ASSUME_KERNEL

LD_LIBRARY_PATH=/symbol/bp/lib:/lib:/usr/lib:/usr/local/lib
##### LD_LIBRARY_PATH=/symbol/lib:/symbol/usr/lib:/symbol/bp/lib:/lib:/usr/lib:/usr/local/lib
export LD_LIBRARY_PATH
==================================================================================================== ==
This a part of the shell script that sets LD_ASSUME_KERNEL and LD_LIBRARY_PATH.
The executable in question is compiled for kernel 2.2.5.
Here is the file program output : sessmgr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

And here is the "ls -l" you requested
lrwxrwxrwx 1 root root 23 Jun 15 19:08 /lib/libcrypt.so.1 -> /lib/libcrypt-2.14.1.so

Thank you very much again
Best regards
Christos

please "ls -l /lib/libcrypt-2.14.1.so", to see whether it is existant, and see the permision.

and also can use the nm or ldd to /lib/libcrypt-2.14.1.so, to see whether it is valid.

all above is ok, then please cp it to your current directory (which your sessmgr locates), and rename it to libcrypt.so.1. and run again.

if still failed. we can write a test program, use dlopen, dlsym, dlclose (you can man dlopen to get enough help information) to test the libcrypt.so.1.

if the test is ok, then delete current directory libcrypt.so.1, and test again, if still ok, then it means libcrypt.so.1 is no problem, and the error which "sessmgr" generated is not the root cause of the issue (it is only the direct cause).

: )


IF all what I said above happened, then you can solve it in this way:

1) skip the program loading libraries in Makefile, to see what symbols can not be found.

2) comment all the calls for the unresolved symbols in your source code (maybe 90% source code must "deleted")

3) for basic symbols which not relative with libcrypt directly or indirectly, can let them uncomment (it will restore more than 85% source code).

4) for unresolved symbols, you can use nm or ldd (or another tools) to see which shared libraries they are located on, and then link them.

Please step by step to do these things, and be careful all the outputs of compiler and linker(need set -Wall), not skip every error and warning.

for every error or warning, if you do not know the meaning (or not know how to solve), you can ask the relative question here (in this thread).



Hope these information above may be helpful for you.

: )

Hello there
Thank you again for the reply

That is the output of ldd -v

linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7571000)
/lib/ld-linux.so.2 (0xb76f7000)

Version information:
/lib/libcrypt-2.14.1.so:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

I also tried co cp the the library in the current directory as libcrypt.so.1 But nothing
I also changed the the mode of /lib/libcrypt-2.14.1.so to 777 But nothing again (Same message).

Unfortunately I have NOT the source code for "sessmgr" So I can't compile or relink
Looks like a desparate situation... And even more because all other binaries in the package are running without any problems

Thank you very much again
Best regards
Christos

Ok, now I assume that you are also the tester or user of sessmgr, not the implementor of it (you can not get source code, it is not open source)

I think you can solve it in this way.

1) write a test program to test libcrypto.so, (can use dlopen, dlsym, dlclose lib c function to test, you can man dlopen to get more help).

2) if libcrypto.so truly no problem (mostly it is), can examine all logs of sessmgr outputs (maybe user verbos parameter, which is -v to let it output more logs).

3) find the help informations about it (relative local document, or google).

4) if all of above can not solve it (maybe truly happen), I think you can contact with the product provider (support team).


: )



Of cause has another way which can find the root cause of it, but it need more programming and disassemble skills:

1) use gdb to debug sessmgr (which is release version, and no source code)

2) set break point to dlopen function call.

3) run sessmgr in gdb.

4) when break point occur, can examine the input parameters and output results.

5) can also step into it to know more details of .so.

6) Please notice, for loading shared library, the disassembly code is a little complex, you truly need familiar with disassemble and know the shared library loading work flow, firstly.

7) I am sure, it is truly can get the root cause of this issue, but may be not quit suitable for normal users or testers.



At last, maybe I can not truly help you to solve the issue, but I hope these information are helpful for you.

: )

You get the same error if a library libcrypt.so.1 depends on isn't. do an ldd on it. I recently had a partial upgrade problem that caused this error.

Hello there
Thank you for your reply

here is the ldd you recommended

# ldd /lib/libcrypt.so.1
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7556000)
/lib/ld-linux.so.2 (0xb76dc000)

does this ring any bell ??

Best regards
Christos

Also here is the output of ldd -v

# ldd -v /lib/libcrypt.so.1
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb75b7000)
/lib/ld-linux.so.2 (0xb773d000)

Version information:
/lib/libcrypt.so.1:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

by the way I run opensuse 12.1

Best regards again
Christos

I suggest to write a test for loading libcrypt.so.1.

1) If load succeed and get the symbol in it is ok, it proves libcrypt.so.1 is OK.

2) If load failed or get the symbol in it faild, it proves libcrypt.so.1 has issue.


we can use dlopen, dlsym, dlclose for test it (can man dlopen to get complete help information)

: )

Thank you very much again buddy

i WILL TRY it

Best regards
Christos