Problems with shared libraries

Hi,

Just tried to run the Linux client. I get this:

bin/secondlife-bin: error while loading shared libraries: libz.so: cannot open shared object file: No such file or directory

I tried setting LD_LIBRAY_PATH to the lib directory and even copied the libraries to /usr/local/lib - no luck.

This is on Ubuntu Breezy. Anyone else get this?

Yes, I did
AMD64 version

I just renamed lib/libz.so.1 to lib/libz.so and then it did work

Try this:

cd SecondLife-linux-02012006/lib
ln -s libz.so.1 libz.so

Yes, you shouldn't be running the binary directly, you should use the ./secondlife script. If you must, use:

% LD_LIBRARY_PATH=lib bin/secondlife-bin


Ouch! Do *not* do things like that! You could be overwriting your system libraries.

- C.

Created the symlink and now get:

bin/secondlife-bin: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

libstdc++.so.5 seems to be omitted from enough distros that the linux versions of Doom3 and Quake4 ship with a version bundled. You can probably just use the version from the linux Doom3/Quake4 demos! I guess it would be good if SL bundled this lib too, and any other vaguely-possibly-maybe-missing ones. I dunno.

Zane, please cut and paste the output from the following commands:

cd SecondLife-linux-02012006
LD_LIBRARY_PATH=lib ldd bin/secondlife-bin

I had the same error, managed to fix it and get sl running by installing a copy of gcc3.2, fedora 4 is shipping with gcc 4.0

Yeah, basically if your system is using gcc-4 you're going to have a newer version of the libstdc++ library than the client can use, so if there's a gcc-3.x (3.3.6 here) package available for your distro, drop that in and the problem should go right away).

I get an error as well. System (uname -a): Linux huskeh 2.6.15-20-amd64-k8 #1 SMP PREEMPT Tue Apr 4 18:03:46 UTC 2006 x86_64 GNU/Linux

bin/secondlife-bin: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory

--edit--
I should add more so this has context. libuuid.so.1 exists in /lib where it should be as a symlink to libuuid.so.1.2 and even when the sym link is replaced with libuuid.so.1 it fails.
Output from: LD_LIBRARY_PATH=lib ldd bin/secondlife-bin

cut to the only file not found: libuuid.so.1 => not found

I had this problem in Ubuntu Dapper (latest as of a few days ago), but I think it was because I was on an AMD64 platform and it needs 32-bit libraries. Fixed it by running secondlife inside a 32-bit chroot. We really need a 64-bit port of the SL client...

The libraries are supposed to be 32 bit compatible. libuuid is 64 bit but that shouldn't matter. It seems odd that the other 64 bit libs did not throw out like this one did.

--edit--
Using 'linux32 ./secondelife' gives the same error, this quite likely is not a 32/64 bit related problem. Anyone else have an idea.

linux32 uname -a -> Linux huskeh 2.6.15-20-amd64-k8 #1 SMP PREEMPT Tue Apr 4 18:03:46 UTC 2006 i686 GNU/Linux

uname -a -> Linux huskeh 2.6.15-20-amd64-k8 #1 SMP PREEMPT Tue Apr 4 18:03:46 UTC 2006 x86_64 GNU/Linux

--edit #2--

That was the problem. libuuid.so.1 in Ubuntu Dapper Drake x86_64 is not reverse compatible to 32 mode with SL. This was the only thing keeping it from running on the 64bit system, libuuid.so.1 should probably come with SL as 32bit where secondlife-bin knows where to look at it. Otherwise people will have to install the i386 chroot environment to get the library needed to run secondlife. Or a x86_64 port would be nice too.

How about 24 bit color depth?

well i have the same problem, so i may as well do this as well~ here i get this

linux-gate.so.1 => (0xffffe000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7f56000)
libGLU.so.1 => lib/libGLU.so.1 (0xb7ed9000)
libSDL-1.2.so.0 => lib/libSDL-1.2.so.0 (0xb7e4a000)
libapr-1.so.0 => lib/libapr-1.so.0 (0xb7e27000)
libaprutil-1.so.0 => lib/libaprutil-1.so.0 (0xb7e12000)
libboost_regex-gcc-1_32.so.1.32.0 => lib/libboost_regex-gcc-1_32.so.1.32.0 (0xb7d99000)
libcrypto.so.0.9.7 => lib/libcrypto.so.0.9.7 (0xb7ca6000)
libcurl.so.3 => lib/libcurl.so.3 (0xb7c78000)
libexpat.so.1 => lib/libexpat.so.1 (0xb7c58000)
libfreetype.so.6 => lib/libfreetype.so.6 (0xb7bee000)
libjpeg.so => lib/libjpeg.so (0xb7bcd000)
libkdu_v42R.so => lib/libkdu_v42R.so (0xb7b4e000)
libogg.so.0 => lib/libogg.so.0 (0xb7b49000)
libssl.so.0.9.7 => lib/libssl.so.0.9.7 (0xb7b1b000)
libvorbis.so.0 => lib/libvorbis.so.0 (0xb7afc000)
libvorbisenc.so.0 => lib/libvorbisenc.so.0 (0xb7a84000)
libvorbisfile.so.0 => lib/libvorbisfile.so.0 (0xb7a7e000)
libxmlrpc.so.0 => lib/libxmlrpc.so.0 (0xb7a56000)
libz.so => lib/libz.so (0xb7a43000)
libstdc++.so.5 => lib/libstdc++.so.5 (0xb7989000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7967000)
libgcc_s.so.1 => lib/libgcc_s.so.1 (0xb795e000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb782e000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7748000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb773b000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7736000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7724000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7721000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7719000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7711000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb76e4000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb76e1000)
libdb-4.2.so => not found
libz.so.1 => lib/libz.so.1 (0xb76cd000)
/lib/ld-linux.so.2 (0xb7fce000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb76ca000)

Once again the libdb-4.2.so problem.

Please do a forum search on this library (Berkeley Database Library Version 4.2) and install it (if you are on a 64 bit machine, install the 32 bit compatibility version).

If you're experienced with the command line, you can also create a symlink from a newer libdb (say, 4.3) to 4.2.

yeah, i did that now i get a fcuken error msg,