Trouble Installing J Microvision

[Preston Kutzner]

On Jan 24, 2009, at 3:22 PM, hippie dream wrote:

>> installing libexpat1 only installs a file called libexpat.so.1 in / 
>> usr/
>> lib/  You can try the following to see if it works for you:
>>
>>> cd /usr/lib
>>> sudo ln -s libexpat.so.1 libexpat.so.0
>>> sudo ldconfig
>>
>> Then try installing JMVision again.
>>
>> You can always find out what files are installed by a package by
>> typing 'dpkg -L <package_name>' at the command-line.
>>
>> Nice. That did the trick. Just for learning sake, did this command:
>>
>>> sudo ln -s libexpat.so.1 libexpat.so.0
>>
>> just tell the system to recognize so.1 as so.0?
>>
>> Thanks for the tips. It is always nice when someone gives you the  
>> tools to
>> figure future problems like this out by themselves.
>>
>> Thanks alot!

You're welcome.  Yes, basically what that command does is create a  
symbolic link (symlink) to libexpat.so.1 from libexpat.so.0.  It's a  
similar concept to "shortcuts" in Windows, if you're more familiar  
with that OS.

If you do an "ls -l /usr/lib/libexpat.so.0' you'll probably something  
(in the right-hand-most column) "libexpat.so.0 -> libexpat.so.1"  This  
shows you that the file is really just a symlink.  The left side is  
the link name, and the right side is the file that it points to (hence  
the '->').  HTH.  Unfortunately, sometimes when using 3rd-party  
applications that run under Linux, especially when they're self- 
contained binaries (meaning you don't have to compile them yourself),  
they wind up looking for specific filenames.  This is usually because  
they're compiled against an older version of a library installed on  
your system.  There's not much you can do about it, other than fool  
the program into thinking those files are there.

Do note that the symlink trick doesn't always work.  If a program is  
compiled against an old version of a library, and the library's  
maintainers have removed or changed functionality in the library that  
the program you're trying to use depends on, the symlink trick won't  
work.  In that case you either have to find and install the old  
version of the library along-side the currently installed version, or  
you have to either re-compile the 3rd-party application against the  
new libraries, or get the vendor to do that for you.  It doesn't hurt  
to try this trick first though.

If you try the trick, and it doesn't work, you can remove the symlink  
as you do a regular file "rm <link_name>".  It will remove the  
symlink, but won't remove the file it's linked to.  Also note that if  
a future upgrade of the library changes the .so's filename again, you  
might need to change your link again as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20090124/90f6d6f4/attachment.sig>