Architectures Besides x86?

It's great to see a Linux version of SL, and I highly commend the SL team(s) for that. There's one little problem, however, that should at least be addressed and hopefully be solved: Linux is not a single architecture OS, yet the "Linux" binary is limited to the x86 platform. I, like many others, choose to run Linux on a PowerPC architecture and therefore can't play SL.

Since SL is run on Wine (IIRC), which runs on many Linux-supported architectures, it should be quite possible to port SL to other architectures. It might even be as simple as dropping the code on a sample of the target architecture and compiling normally. That said, is there any hope of seeing Linux SL builds for at least a couple of the most popular architectures on which Linux runs? (I'm not holding out hope for a source release).

If there is no chance of this happening, I would at least advise that a note appear on the website stating that the Linux version is only for x86. I suspect that part of this is that the Linux version is still alpha status and doesn't even have it's own system requirements page yet, but it might be worth changing the download link to read 'x86 Linux' or adding an informative check of /proc to the launching script. Seeing './secondlife: line 4: bin/secondlife-bin: cannot execute binary file' could be somewhat confusing for an inexperienced Linux user.

In any case, keep up the good work, dev team.

All good points. AFAIK the linux binary is native and has nothing to do with wine.

It is possible to run the windows binary under wine, and this should work regardless of architecture.

But with the native binary, as you say, it may be as simple as recompiling the source on the target arch.

I think the Mac version of Second Life comes in a combined i386 / PowerPC flavor. Maybe they could tap in there and release it for Linux/PowerPC, too. I would not hold my breath, though. Linux is no top priority for LL at all at the moment, so I think all we can hope for is an updated i386 client for the time being.

I agree that the Linux binary on the page should be labeled i386, though. Maybe we should send a mail to the web developers to have that information added.

Just to point out that Wine itself is x86 only unless you use an i386 CPU emulator underneath.

(If you do use a CPU emulator on non-x86 architecture you can forget running any graphical apps tho).

Didn't know that.. Thanks.

Hmm, thanks for pointing that out, I had not realized that. But, I suppose it makes sense considering that Wine makes use of Windows DLLs which must be x86 only.

However, if the client is Linux-native then my point still stands. I thought I read somewhere that there is a developer who focuses solely on the Linux port. Perhaps he or she could find the time for a cross-compile or two. *crosses fingers*

I dont see why it'd be a problem to compile the source on another computer :-/

Consider this:

Not all CPU's have the same size for native integers, nor do they all store them the same way.

These use native 32-bit integers: Intel Pentium series, AMD Athlon series, PowerPC, ARM, Sparc.

These use native 64-bit integers: Intel "IA64" and "EM64T" series, AMD Athlon 64 series (aka AMD64), PPC64 and UltraSparc 64.

Now they store them is also very important, especially when communicating to the SL servers and storing data so it is portable between different CPU's. If I store a value (in hexadecimal, as it's easier to illustrate) of 0x11223344 into an integer in memory, some chips will store it as 0x11, 0x22, 0x33, 0x44 in that order -- little endian. Others will reverse it: 0x44, 0x33, 0x22, 0x11. That is big endian.

Intel and AMD is little endian. PPC is big.

No doubt there are potenial pitfalls involved in porting, the basics of which you've done a fine job of presenting, but it's all subject to the coding habits of the development team. A team which codes in a portable way is often able to avoid most -- if not all -- of these issues.

Also, bear in mind that the client already runs on the PPC architecture as there is a Mac version. That said, many of these porting issues /should/ have already been dealt with, hopefully in an extensible a way (perhaps a few #ifdefs and #defines here and there). This is especially true of a Linux PPC version.

Cheers.