Libraries (libopenjpeg.so.2) not found?

I'm attempting to run SL Release Candidate 1.21.4.98167 on an EeePC subnotebook, running the default Xandros Linux install from Asus. However, I run into the following issue:

"bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: libopenjpeg.so.2: cannot open shared object file: No such file or directory".

Two important notes:
-1: I am running SL from the basic, unmodified download of the Linux client tar.bz2 from the website, and running it from the ./secondlife script. I have not changed or altered the script or other files in any way whatsoever.
-2: The ONLY possible oddity to my configuration, other than it being an EeePC, is that I have SL installed onto an SDHC card

The steps I have run to install SecondLife on the SDHC card for the EEEPC are at http://forum.eeeuser.com/viewtopic.php?id=14280

I would appreciate any help and suggestions that can be provided regarding this issue.

i386PC: apt-cache search libopenjpeg
libopenjpeg-dev - development files for libopenjpeg2, a JPEG 2000 image library
libopenjpeg2 - JPEG 2000 image compression/decompression library
libopenjpeg2-dbg - debug symbols for libopenjpeg2, a JPEG 2000 image library
libopenjpeg-dbg - Debug symbols for libopenjpeg, a JPEG2000 library

libopenjpeg is probably not (correctly) installed on your system. Do so with any package manager supplied with your distribution. Or just run a terminal as root and enter:

apt-get install libopenjpeg-dev

or

apt-get install libopenjpeg2

You could also try to use the OpenJPEG library supplied with the viewer, but i think you need to recompile the viewer first to flag it to use supplied libraries by Lindenlab. Best ask independent compilers of the code present in these forums.

That library should already be there in the 'lib' directory where you unpacked the viewer. If it's not then your archive is probably corrupt (please redownload - the latest is now 1.21.5). If it's there then... I'm quite baffled as to why it's not being found. Perhaps a 64-bit/32-bit issue?

The library *is* present in the lib directory, as Tofu mentioned; I'm sorry for not having mentioned that. The files are there, and this is the third time I've downloaded it. I'm pretty sure that the Eee is running 32bit Xandros.I know I've seen someone else mention this problem as well when I was searching for libopenjpeg.so.2 on Google. Their solution was to move the files to a different directory, then symlink the new directory to the current libs directory. I gave it a quick try, but it didn't produce any results.

It unpacks without reporting any errors. Additionally, if I try the non-RC client, I get the same error, but with libELFIO instead. The files are present in the lib directory, it's just SL is not seeing them.

From what I can tell, it's not finding the libs folder - perhaps it's not getting the ref for it, or for whatever reason it's not identifying the correct location. How precisely does SL locate the libraries it uses? Is it hard-coded, is it a system variable, is it in an INI?

Is there a way I can give more debug information for this error? There are no other errors printed to the terminal display when running it, so I'm not sure if there *is* anything else I can offer.

Libraries to be used from OS or supplied by the archive from Lindenlab, is indicated in a compilation-script that runs prior to generating the release-candidate. So it's more or less 'hard coded'. I am not sure to which the viewer looks by default. The latter seems more likely.

Check if /usr/lib or /usr/local/lib contains libopenjpeg.so and the like to see if libopenjpeg is installed systemwide.

i386PC:/usr/lib# ls libopenjpeg*
libopenjpeg-2.1.3.0.so
libopenjpeg.a
libopenjpeg.so -> libopenjpeg.so.2
libopenjpeg.so.2 -> libopenjpeg-2.1.3.0.so

Maybe re-symlink it and 'ldconfig'. The environment setting of your LD_LIBRARY_PATH seems not to work here.... One could look into the file /etc/ld.so.conf to see what is used by default. And the directory /etc/ld.so.conf.d/ if presents might reveal some clues too.

ow.. 'ldconfig -v | grep openjpeg' to see what you already got...



.. and sorry if this does not sound like English to you .. i do not know what i'm saying myself here..

.. and don't listen to Tofu Linden.. he will only keep you away from any solution.

Solution, finally:

The Asus EeePC 700 series, by default, mounts a removable device to a directory such as "/media/D:". SecondLife uses "LD_LIBRARY_PATH" to find its libraries, which is a colon-delimited list of directories.

The problem comes when SL tries to run from the SD card, and finds it's current working directory is thus:
/media/D:/SecondLife-i686-etc
Making it's lib directory:
/media/D:/SecondLife-i686-etc/lib

Since the current working directory contains a colon, and LD_LIBRARY_PATH is a colon-delimited list, SecondLife is unable to find it's own library folder.

In order to fix this, I had to do quite a bit of work for someone who has not really delved into device mounting. The instructions I followed can be found at http://wiki.eeeuser.com/howto:automountusbstorage

The process involves telling the EEE to search for the SD card (or other USB device) BEFORE any other possible devices, so it doesn't receive the script-assigned name, and adding an entry to /etc/fstab to specify the mount directory (make SURE it does not have a colon!)

Is there any chance that a summary of this problem and solution could be added to a stickied list of fixes? I had a hell of a time trying to find anything related to this issue by the library filename, "libopenjpeg.so.2", and I'm sure I'm not the only one to have come across this. I merely ask that if it does get stickied, please include the files "libopenjpeg.so.2" and "libELFIO.so" to the body, so once it's indexed, later searchers can locate it.

Perhaps

export LD_LIBRARYPATH=$LD_LIBRARY_PATH:/media/D:/SecondLife-i686-etc/lib

does the trick too ?

All that that will do is set your library path to the existing library path, plus /media/D, plus /SecondLife-i686-etc/lib.