vi returns shared library error

[Omar Alvi_1]

Hi,

When running vi, the following is returned

#vi
/usr/lib/dld.sl: Can't open shared library:
/home/jbasebld/4.0_rels/jbc4.0.4.4/l
ib/libjbase.sl
/usr/lib/dld.sl: No such file or directory
Abort(coredump)
#

vi used to run perfectly fine.

I've checked the $PATH variable, everything in order there.

Any ideas

Regards,

-Alvi

[Olivier Decorse]

Hi,

can you verify all your package, searching for something not properly installed with :
swverifty \*

Also, verify any modification on SHLIB_PATH and LD_LIBRARY_PATH var.

Olivier.

[Sridhar Bhaskarla]

Hi Alvi,

Is this error only for vi or any other editor like ed, ex etc.,?.

The shared lib that is complaining about is not a OS standard library. Looked like either you have compiled your own vi or you are executing some other non-default vi. Do

$which vi

$what /usr/bin/vi

and see which vi you are using and it's version. Try directly "/usr/bin/vi"

-Sri

[Muthukumar_5]

Are you trying anyother vi other then default one. Can you check where is your vi and version as,

whereis vi / which vi
what vi

If your binary is not in relative PATH then, it will try to check absolute PATH so that it will make problem on dld.sl library.

You can solve this by setting SHLIB_PATH=/location-to-binary

Check it out and give the details.

[Steven E. Protter]

The common fix for that error is the SHLIB_PATH variable.

The thing is, vi has always worked on all of my boxes for users without that variable even being set.

Maybe the libraries are missing. Do all of the files in the error message actually exist? What has been done to this system lately?

SEP

[Omar Alvi_1]

Hi All,

Thanks for the replies

The SHLIB_PATH variable was empty

I found that comparing two machines there's some problem with the vi of this machine.

should be

#ll /usr/bin/vi
-r-xr-xr-t 6 bin bin 249856 May 22 2002 /usr/bin/vi

and it actually is

#ll /usr/bin/vi
-r-xr-xr-x 8 nccidemo users 57344 Feb 24 2003 /usr/bin/vi

and the output for what vi

#what /usr/bin/vi
/usr/bin/vi:
$Revision: 92453-07 linker linker crt0.o B.11.33 020605 $

Should I simply copy the file from the other machine to this one ... or how else should I proceed?

Thanks and Regards,

-Alvi

[Cheryl Griffin · Accepted solution]

What operating system are you on?
You could install the latest vi patch:
http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|patch.breadcrumb.patchDetail{PHCO_27057,hpux:800:11:11}|&patchid=PHCO_27057&context=hpux:800:11:11
Reboot = No

[Olivier Decorse]

Hello Omar.
Good news that you find the problem.
But bad news to know that some user/application can overwrite one of the system file ! Any idea of what is the nccidemo ?
Mat be there is a security leak on your box. Install and run "HP System Healthcheck" product (for free !), to search for any problem :
http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=SHCBASE01

For the vi file, just put the one from the other server, and adjust the owner/right of the file.

Olivier.

PS : Please don't forget to ASSIGN POINTS : it is very important for us to know if response helps you (or not !!) and you will have more chance to receive responses !

[Sridhar Bhaskarla]

Hi Alvi,

Two things attracted my attention. The permissions on the file. vi is supposed to have sticky bit on and the size. You can confirm it by running the command

ldd /usr/bin/vi

It should show all the dynamically linked shared libraries used by that executables. It shouldn't have refereces to any other libraries other than that in /usr/lib structure.

If this is system is completely identical (OS level, patch level), then you can copy the file from the other system with the same permissions. Otherwise, install the latest vi patch and that should take care of replacing the fake vi.

It is not a good idea to replace system default binaries with your compiled ones as they will be replaced by patch installs along with the problems like this. Keep them in /usr/local/bin or any other directories and use them.

-Sri

-Sri

[Omar Alvi_1]

Cheryl, Olivier and Sridhar,

Thanks, replaced the executable with the one from the other system and changed ownership, now everything is fine.

Don't seem to have an idea since when this file has existed ... is definitely something unwarranted.

Thanks again. can always trust itrc :)

Regards,

-Alvi