Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

RC7 on X86_64 Linux halts on error before login screen

Stephani Honi
Registered User
Join date: 11 Nov 2007
Posts: 7
05-22-2008 07:41
I have all the necessary 32bit compatibility libs installed.
I have a Core Duo running Fedora Core 7 with all updates and security patches in place.

This same system runs other official SL viewers (and CoolRelease viewers).
I've been using SL since version 1.18.3.5.
This is the first time SL refused to start for me.
This issue is a showstopper for me.

When I go to run, I get this error from the console:

=======================================================================================
$ ./secondlife
Running from /home/reindeer/Programs/SecondLife_i686_1_20_7_87883_RELEASECANDIDATE
bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory
*** Unclean shutdown. ***

You are running the Second Life Viewer on a x86_64 platform. The
most common problems when launching the Viewer (particularly
'bin/do-not-directly-run-secondlife-bin: not found' and 'error while
loading shared libraries') may be solved by installing your Linux
distribution's 32-bit compatibility packages.
For example, on Ubuntu and other Debian-based Linuxes you might run:
$ sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl

*******************************************************
This is a BETA release of the Second Life linux client.
Thank you for testing!
Please see README-linux.txt before reporting problems.
=======================================================================================

I can then run version 1.18.3.5 without issue.
This is a serious issue because the previous release (which worked fine), RC6, is now deprecated and cannot be used. I'm thankful that 1.18.3.5 is not yet deprecated.

I have expat-1.95.8-9.i386.rpm expat-1.95.8-9.x86_64.rpm currently installed,
which contain libexpat.so.0 <--Fedora Core 7
I'm guessing that Fedora Core 8 and 9 contain libexpat.so.1, as there is a newer version of expat.
I have no way to confirm this.
The newer version is expat-2.0.1-5, according to yum.
sacha Magne
Bratty Kitsune Boy
Join date: 20 Aug 2007
Posts: 81
05-22-2008 22:54
check where your libexpat is

mine is under /usr/lib (ubuntu)
Stephani Honi
Registered User
Join date: 11 Nov 2007
Posts: 7
Bug Filed
05-23-2008 09:55
From: sacha Magne
check where your libexpat is

mine is under /usr/lib (ubuntu)



[steffi@localhost ~]$ locate libexpat
/lib/libexpat.so.0
/lib/libexpat.so.0.5.0
/lib64/libexpat.so.0
/lib64/libexpat.so.0.5.0
/usr/lib/libexpat.a
/usr/lib/libexpat.la
/usr/lib/libexpat.so
/usr/lib64/libexpat.a
/usr/lib64/libexpat.la
/usr/lib64/libexpat.so


Does it matter? I'm using Fedora Core 7.
It's not the right version, and I can't upgrade without breaking a good many programs that depend on it.
Is the only solution upgrading to Fedora Core 8? Version 9 is not compatible with nVidia's drivers for my GeForce 7600 card. Its seems like a lot of work just for this one lib.

Bug filed: VWR-7342, which also shows my filed bug VWR-7349 as a dupe (filed simultaniously no doubt):
http://jira.secondlife.com/browse/VWR-7342
Allen Kerensky
Registered User
Join date: 16 Aug 2004
Posts: 95
Have you tried...
05-23-2008 18:32
Dropping a copy of the 32-bit expat libs into the $SLHOME/lib subdirectory?
You might also copy an expat from the last working version for you, into that directory as well.

The SL Wiki ( http://wiki.secondlife.com/ ) has an open-source portal which explains exactly how the viewer is built against expat. May some clues there for you, if you review the sections of the compile and build documentation that relates to expat.

With Fedora 7 probably days away from end of life, it might be bullet-chewing time...
Once its end of life, support becomes "at whim" of the legacy folks.
Stephani Honi
Registered User
Join date: 11 Nov 2007
Posts: 7
05-24-2008 01:44
I linked my existing libexpat.so.0 to a pointer that spoofs it as libexpat.so.1, and it works just fine. Dropped the link into the ~SLHOME/libs dir. Working now.