64 bit

May I kindly suggest that people who have no clue what they are talking about stay away from topics they don't understand?

This is a technical board and I don't appreciate that technical topics are closed.

Thanks Katt!

Boy

Well, I suppose the discussion about 64bit builds should be continued here .

I appreciate the work done on OMVViewer, but
1 - I am an OpenSuse user, I don't really care for Debian/Buntu packages!
2 - I'd like to apply patches to my build, thus I want to compile it myself anyway.

So my question is: where can I find a tutorial for compiling it in 64bit ?
I guess that https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 is a good start, but won't it default to 32bit architecture builds?
I read also that OMV is not really different from the official secondlife. Should I take there is really a few things to change to make it compile for 64bit?

Other questions:
Fmod being closed source and providing only 32bit binaries, has the current OMVViewer any sound?
If not, building SLviewer from trunk, as fmod is being replaced by something else, wouldn't that make the sound work again?

There is no code in the official source that supports 64bit builds (or even SSE2 +). If you look at the previous thread Katt closed (without understanding anything) there will also be no 64bit developments from LL in the near future. Most alternative viewers therefore build up on the existing 32bit platform.

I do myself quite some stuff in Unix environments, I build the Cool Viewer for Windows. As much as I would see some developments for 64bit viewers, I don't think it is worth to invest time into porting it properly *yet*. The code changes too fast, you only need to look at the RC's. And there's a new official version every 3 or 4 months.

It would be cool if we could set something in motion. So more people become interested so better. Closing threads asking for 64bit versions is certainly the wrong way.

Boy

Cron Stardust has posted how he did it on Gentoo AMD64 at
https://wiki.secondlife.com/wiki/User:Cron_Stardust#Compiling_on_Gentoo_AMD64

While the process might probably be different for other 64bit distributions, I guess you're best off basing on his work there, which is again based on the (generic and 32bit centric) description at
https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake

Good Luck!

Sounds like a personal problem. Nobody in their right mind who isn't paid to do so uses RPM-based distros and hasn't since the mid-1990s. LR themselves run their servers and test the slviewer (omvviewer's upstream) against debian, so between that and RPM being worse than Windows in terms of package management, you're really putting yourself at a disadvantage.

If that were true, omvviewer wouldn't have a 64-bit version. omvviewer is literally slviewer with the trademarks removed.

Oh, I did not intend to start a distro war here...
Maybe I should copy/paste your post into an OpenSuse or Fedora forum and see what they think of it ^^.
Nobody in their right mind would use a distro who's latest stable came before the latest glaciation... or the other noobodrom...
Just kidding, of course. OpenSuse just works, and most of the other distros too (rpm or deb based alike).
My remark it was just a stupid pretext for what followed in my post.

You are right. I was referring to the statement from Tofu "There are no plans to provide a 64-bit Linux viewer release from Linden Lab for the forseeable future". Doesn't mean there is no source that supports 64bit builds.

I have been working with the RPM build system from the other side... as a package creator.

All I can say is that the folks at Red Hat and Suse must REALLY have a thing for pain if they actually like this monstrosity.

So you would suggest that I download the source deb package and try to build it on my box?
(as far as I can tell, OMVViewer hasn't even .tar.bz2 archives or a svn)

I personally use the SVN tarballs for all I do. I'm not building under Linux but I do all the patching there, usually under Ubuntu. Also having a 64bit Arch on the laptop.

The latest 1.22 RC version you can find here: http://svn.secondlife.com/trac/linden/changeset/1645

Joking aside, Windows updates considerably less often. I'd say it's a tad more suicidal to run software that hasn't been carefully tested. And if you are a heatseeker, there's always Testing, which many places do use in a production environment.

I don't suggest that, as Ubuntu doesn't agree with Debian on package names like they should, and RPM distros take the absurdity one step further by allowing per-file dependencies that simply has no equivalent in sane package management.

If you really want to give it a go, grab git and check it out of svn. http://www.byteme.org.uk/secondlife/secondlife-svn.html

I know what you mean. When I switched to Linux back in the 1990s, I started on Red Hat, and RPM's insanity and propensity for launching users into circular, unresolvable dependency hell. It almost drove me back to Windows until someone got me hip to Debian. Sure, RPM distros have all kinds of fancy, automatic package managers, but none of them seem to handle file dependencies properly, and an obnoxiously large number of RPM packages pull this move. I'm SOOOO glad that this kind of dependency is not implemented, not supported and generally considered the Wrong Thing outside the RPM world. Given that the problems with RPM get worse with time with attempts to fix the problem usually compounding them, it makes me wonder why Red Hat, et. al., don't just adopt what works.

Though knowing Red Hat, if they did that, they'd screw over the .deb world by continuing to insist on nonsensical package names. I'm not sure what's in the water out in Raleigh, but it seems to be preventing them from doing the right thing.

Baloo, that link for the debian source is a little out of date (although i am trying to keep the last stable version there upto date). All RC versions and development/patch merging etc is happening under the new (still not quite finished site) http://omvviewer.byteme.org.uk.

Something i really would like to do is get the source so its more generic for any linux distro that wants to build from source not just debian/ubuntu. But the new source tree is git/top-git managed to keep my sanity when rebasing to new upstream LL versions.

Yogaga,

The reason i don't have a tar.gz/bz2 is because i am following debian package guidelines. my tar.gz IS the LL upstream code unaltered, there is then a diff.gz with a debain source and this adds by debian/ control directory and all the patches i will apply at build time. My git repository contains an upstream branch which is the unaltered LL code, a master branch where we do the debian/ control stuff and various branches one for each patch. This gets generated into what i just described.

If you want sometimg close to a tarball release you can grab the source directly out of the apt repository (if you do not have a system that supports debs/apt) from http://apt.byteme.org.uk/pool/main/o/omvviewer/, you will see a orig.tar.gz and a diff.gz there for both the 1.21.6 and the 1.22.4 (sorry 5 is not pushed yet). Patches are applied with quilt and the patches and series can be found under debian/patches/.

If you are brave enough to try the new top git controlled git, instructions are staring to appear at http://omvviewer.byteme.org.uk/source.shtml. I have managed also taking the debian source orig.gz and diff.gz and with cygwin to build omvviewer on windows successfully. so it can be done cross platform/distro. I've not yet done this directly from git although i should and then document it.

i'm not sure if any of my explanations made very much sense so if you need any more help working with my source either ask back here or ping me on any of the contact methods from the new site

I'm running 64-bit Fedora Core 9 on an Athlon 64 4000+. From the 1.21 branch I managed to cross-compile a 32-bit binary using the pre-packaged libraries (I compiled a 64-bit version too but the performance stunk at the time for some reason), but I haven't been able to again for the 1.22 branch (I think it has to do with the fact that the configuration script now wants to download what libraries it thinks is appropriate for the system instead of using pre-packaged ones).

However, I compiled a 64-bit binary on 1.22 (SVN check-out on Jan. 7). Fmod is, of course, turned off (no audio), but almost everything else seems to work pretty well (the performance even seems decent now). Getting the right libraries and (especially!) includes was a pain. In fact, where the ccmake config has an include path, I almost invariably had to instead add a '-I...' flag to the compiler options instead of just setting that configuration parameter. That is with STANDALONE turned on.

Okay. Actually one bug I've noticed is that SL is unable to change the mouse cursor. So there's no feedback, for example, when you hover over a touch-enabled object.

Oh. I have to add /usr/local/lib64 to my LD_LIBRARY_PATH before executing, because that's where I put some of those darned libraries.

----

CPU: AMD Athlon(tm) 64 Processor 4000+
Memory: 2012 MB
OS Version: Linux 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 EST 2008 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7600 GT/PCI/SSE2
OpenGL Version: 2.1.2 NVIDIA 177.82

package types, all have their own pro's and cons.

RPM has some need mean advantages over DEB
and vice versa..

lol, so do non rpm/deb packages over rpm/deb and vice versa..
(e.g. slackware's .tgz packages.. or gentoo's Ebuilds)

all in all it doesn't really matter, if you want a quick setup of software, only be sure, your distro of choice has big repositories, or use common used package types, that third party developers supply, so you can easily install it manually.
(most are, either RPM (for various distro's) or DEB (for apt distro's)


anyway.. on topic..
64 Bit, it's not the effort worth. It has more hassle then it delivers back. Many drivers aren't 64Bit capable, many third party software isn't either.. that's a big minus, for usability for endusers (non geeks).
Compatibility and stability issues are also into play. (multiple cross libs, breaking things when updating etc etc etc, been there seen it. Also numerous tests have pointed this out)

And the performance for average usage, is 5 to 10% max extra speed compared to 32Bit, in most cases anyway. (only for heavy packages, like 3d renderers etc)
Many benchmarks have proven it.
So, unless all the software that's being used is completely 64Bit, the profit of using it, is down to zero on the long term.

so, for now stick with the mainstream if you want easy usage and compatibility (lowest risk of breaking things, or diving indepth into the software to find a dirty solution for the mentioned problem)

I agree that this deb vs rpm is completely off-topic (seriously, don't we have something more interesting things to discuss?).

Another off-topic remark is for disagreeing with say Moo: 64bit is usually not a hassle. Just a few issues with the flash plugin (which globally works with nspluginwrapper... and is about to have 64bit builds anyway), and that's all.
32bit Secondlife also works well on 64bit OpenSuse (mostly well, but I don't believe my problems are bitness issues).
So I would say, yes, 64bit hardware is mainstream, and 64bit Linux *is* mainstream too.

Please, developers, stop using this as an argument for making only 32bit builds of your software. Lack of time in regard to the small immediate benefit is a good argument, though.
But please, look at the evolution of the 64bit hardware market share too!

Back to topic, 32bit or 64bit, I still cannot build SLviewer on my system... it seems that develop.py has big troubles using pkginfo for finding .h locations.
I tried both on OpenSuse and ArchLinux (no special wish for installing a Debibuntu now).
Well, I created a huge amount of simlinks so that it can find needed includes, but still I have a compilation error, some type confusion between int and size_t it seems (even after a new "make clean; make".

And who's brave can even have 64 bit flash http://labs.adobe.com/downloads/flashplayer10.html .

64bit is NOT mainstream for desktop usage, because it is cumbersome for most users (mainstream so to say).
It all depends on the usage and experiences, AND willingness to overcome problems (and time ofcourse).
and for performance boost against 32bit is way less then expected/advertised/marketed for now.

Mainstream means in this perspective, general usage, home usage (most users are home users in that perspective).
Mainstream also means, general acceptance and support (availability of software for it) by developers.
Most 64bit installments require cross libs for good compatibility, and there lays the problem!

How isn't it mainstream if you can do exactly the same in 32*and 64bits?
FYI 32bit libraries are installed automatically by the package manager when needed (on OpenSuse at least!).
Where is the cumbersomeness? Is it the 0.02% of your hard drive used for 32bit libs? (and anyway, this will only go down, as more software is ported to 64bit)
For home usage there is *no* difference in most of the cases.

(for the sake of honesty:*I had one 64bit specific problem in my whole experience: just because there was no certified jvm for declaring my incomes for french taxes. The fix was easy: just install firefox-32bit and the 32bit jvm.)

I don't know why there is always that strong opposition when we speak about 64bitness (well, I know, impatient and noisy users might not be totally strangers to this!).
Things take time, but the transition is on its way and will eventually be achieved (I'd say that it has already been achieved except for a few proprietary pieces of software).
One should rather accompany it and keep it smooth (with a well integrated 32bit compatibility layer, for instance), than try to block it.

Maybe because, you are only focussing on YOUR experiences, and not listening to the mainstream users, and/or developers on the globe.
(no offence, but i only see, you talking about you in your post, not generically speaking broadly about the subject, while I do)
I've read many many many forum posts of end users, developers, mailinglists, reviews etc etc..
and i can only come to the conclusion, that the majority of 64bit users have cumbersome experiences if you take all into account (world wide usage).
For now, 32bit is the safe bet, the most stable bet.
It will change, sure, but it's too soon yet. Simple fact.
I know Linux/BSD communities try to stay ahead of the competition, in these fields (too eagerly if you ask me, i know why, to gain more users thus more commercial interrest from commercial developers to make their software linux/bsd compatible)
.. but being able to have such features doesn't mean it's widely accepted, or used.
that are two different things.

It'll be mainstream when everything in 64-bit is as easy to do in 32-bit, just as it was during the 16- to 32-bit transition. It's not today on any platform.

Macintosh. The transition on the Mac has been seamless.

If you are willing to discount the explosive hard disk requirements from shipping statically linked binaries capable of running on three architectures. Most people aren't.