SL on x86_64

Any chances to have a Linux version of Second Life compiled to run on x86_64 (64 bits) platforms?

On my computer it works well with a 32 bit chroot environment.

We all know it'll work in a 32-bit enviroment, and amd64 will also work as it can auto-switch to 32-bits. We're talking compiling it for 64 bits.

Some day I'll do an official x86_64 build, but it'll have to wait until the 32-bit version is in a happy place. Meanwhile, some residents have reported a level of success with their own 64-bit builds of the client from source.

An official x86_64 build would rock!

It would also overcome the need for 32-bit emulation libraries when the existing alpha client is run on 64-bit machines, which could become a severe problem shortly. That would kill two birds with one stone.

Until that happens though, Linden needs to supply the 3 needed gstreamer libraries along with its Linux alpha client, as I mentioned in another post here a few hours ago : here.

Otherwise, people who run 64-bit Linux, and who have always been on a level playing field with 32-bit users of this client, will suddenly find themselves disadvantaged on video, since there are no public 32-bit emulation libraries for gstreamer.

Morg.

Is there a 64 bit version of fmod3.75?

No FMOD3 for 64bits... only the new FMOD4.

Found a way to get video working:
I have both 32 and 64bits Ubuntu Gutsy in my notebook. I moved the /usr/lib/gstream* directory somewhere else, and linked the 32bit directory in there! ln -s /media/sda5/usr/lib/gstream* .

Everything working smoothly!

Using the chroot trick makes SL much slower than normal for me.

So no way Tofu can do a fully-featured 64-bit build then, at least till fmod bites the dust. Time to merge those OpenAL patches

Let me explain how I did it.
I installed a small partition with a 32-bit sidux working on it. There I tested the SL client.

Then I started my normal 64-bit sidux system and switched into the 32-bit CHROOT environment to start the SL-client from there.

You need to install dchroot, if it is not on your system.
And have to add this at the end of /etc/fstab:
##########
# 32 bit chroot
##########
/dev/sdaX /emul/ia32-linux reiserfs defaults 0 0
#/home /emul/ia32-linux/home none bind 0 0
/tmp /emul/ia32-linux/tmp none bind 0 0
/dev /emul/ia32-linux/dev none bind 0 0
/proc /emul/ia32-linux/proc proc defaults 0 0
#########################################

The steps to start are
1) xauth extract XKEY $DISPLAY

2) mv XKEY /emul/ia32-linux/home/whereSLclientIs

3) su - SLclientUser

4) xauth merge XKEY; export DISPLAY=:0.0

Now I can start the SL-client to make it show on my 64-bit desktop

Ok, how do I compile SL in a 64 bits system? I followed the instructions on the website and it just doesn't work for me.

Unless you know otherwise, those 64-bit builds were without sound, because there is no 64-bit FMOD-3.75. I've not heard of anyone replacing FMOD by an open-source solution.

Since I spend a lot of the day following SL's live music scene, a soundless client on my 64-bit box is less than helpful ...

I've been running SL on my x86_64 system without doing anything special for ages. I simply downloaded the package, extracted it and ran it, runs happily, no chroot or anything.

Me too, it's worked fine on x86_64 in 32-bit mode ever since the Linux alpha client came out. The 32-bit emul libs work great.

That situation has changed now though, because of video streaming, which uses gstreamer. The 32-bit alpha client can't use 64-bit gstreamer libs on x86_64, and there are no 32-bit emul libs for gstreamer in distros, and LL hasn't yet supplied them in its package of 32-bit binary libs either. So, the ability of 64-bit Linux systems to work as well as their 32-bit counterparts with the alpha client is now broken.

Morg.

I had video working till the last couple RC versions 1 and 2 came out.
Please check my post about it and see if you can help:

/263/9c/217918/1.html#post1744301

I'm just reviving this thread to point out that a 64-bit native client may actually be the easier option for you, since the code is already fairly 64-bit clean.

Admittedly that can't be done just yet because of FMOD, but Seg's patches overcome that and have been in successful use for months now. It suggests that the path towards a native 64-bit alpha release could be a short one.

And if that's done, it removes the need for you to supply 32-bit gstreamer libraries with your download. Those three libs are currently missing from your lib subdirectory, which makes 64-bit Linux users unable to start video when running the alpha client under 32-bit emulation, since their native 64-bit gstreamer libs won't load.

In other words, incorporating Seg's OpenAL patch would fast-track a 64-bit native client, avoid having to supply gstreamer libs, place 64-bit and 32-bit users on an equal footing, and generally reduce work by making 64-bit just another autobuild. And as a further benefit, it would make the open-source community much happier through removing FMOD.

It's a win-win!

Morg.

Morgaine Dinova, could you point me in the right direction as to use Seg's OpenAL patches?
I suppose they are for compiling in native 64bits right? Do they make sound and video work in 64bit? Where are these patches?

I'm installing Fedora8x86_64 right now on my notebook, and would like to try a build.

I don't have that info, Royer, but I could try to find out.

However, at a meeting of the Open Source group a couple of weeks ago, the issue came up and Seg said something like "Oh I'd better send in that patch then", and a Linden said something like "Yes please do". And others commented on how well it's been working for ages. On that basis. it looks very promising.

So, I'm hoping that Seg sent his patch in, and that the Linden devs took a look at it.

http://www.byteme.org.uk/secondlife-amd64/apt-get-a-secondlife.html

There's a debian solution which I've successfully compiled and run with sound (not tested video yet) under Unbuntu 7.10

Looking at the various patches that installs for the build should give you a good start on a Fedora build

I don't think that helps though. There is no problem with sound after all, but only with video, and that link doesn't show a solution for it.

The problem is that the three 32-bit gstreamer libraries aren't supplied with the download, and a 64-bit Linux that runs the client under 32-bit emulation can't load its native 64-bit gstreamer libraries in their place. Audio works fine under 32-bit emulation on x86_64 because LL supplies the 32-bit FMOD library in its download. Video fails under 32-bit emulation on x86_64 because the corresponding 32-bit gstreamer libs aren't supplied.

It's a relatively new issue. I've been running the Linux alpha client on x86_64 under 32-bit emulation since day 1, very successfully. The current problem arose only when the release started using gstreamer without supplying the 3 libraries. Since that day, x86_64 users of the alpha client haven't been on a par with 32-bit users: enabling video fails for them with "grab_gst_syms: Couldn't load DSO: libgstreamer-0.10.so.0", because you can't load your native 64-bit libs under 32-bit emulation. Native 64-bit gstreamer libs work fine of course in 64-bit apps. They just can't be loaded by the official SL client under 32-bit emulation.

Morg.

And the flip side is that if you compile a x86_64 build yourself to get video, you lose audio because there's no 64 bit version of FMod 3.75, which is at least partially the rationale behind getting OpenAL support merged.

Hehe, indeed.

Which is why I proposed that Tofu could integrate Seg's OpanAL patch to get rid of the annoying and slightly flakey FMOD, and then go straight for a native x86_64 release. If it doesn't work, nothing lost, we'll still be where we are now. But the signs are excellent that not only would it work just fine (from community experience) but that it would also overcome a lot of issues and actually be *less* work overall for Lindens.

Worth a try!

Morg.

Well, there's definitely a desire within LL to replace Fmod - the Jira ticket for Segs OpenAL patch was created by Tofu, for example. Whether or not it will ultimately involve Gstreamer on Windows & Mac remains to be seen, as OpenAL doesn't handle the streaming audio.

I seem to recall seeing stubs in the code for alternative audio effects libs, including OpenAL.

I was replying to Royer Pessoa who wanted a start on compiling x86_64 with the OpenAL patch. 50_add_openAL_audio.dpatch is one of the patches applied in those packages

There is a working version for 64bit linux.

http://sourceforge.net/project/showfiles.php?group_id=191214&package_id=235614&release_id=566375

It uses GStreamer and OpenAL. I'm still trying to get OpenAL to work nicely with ALSA, but maybe somebody can provide clues. Otherwise, video works. Music works. Mozlib also works!

Download debs into its own directory and use 'dpkg -i *.deb' to install. The "dbg" deb package is optional.

Send kudos to Michelle2 Zenovka for the deb work!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Has anyone been able to get SL to run on Fedora 8 64 bit
with installing1 32-bit compatibility packages?? new to 64 bit
world and unsure even how to do this

Wolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFH4bQO3BIrt58Ld3MRAmiBAKCFsmPGkCZV2z8m9xu415LPxAyxhQCgmvNi
w3+70JQ5IxqzKtcQLkbNWLg=
=9Hac
-----END PGP SIGNATURE-----