Linux Viewer

[bennettgoble]

Revive upstream linux builds with the help of viewer contributors.

Why?

The Second Life client has breakout capacity for re-enabling linux viewer builds: most of the connective tissue for building linux remains in the codebase, and linux viewers are actively maintained in forks. In the past, a few familiar excuses have come up whenever this idea is entertained:

• Support Load - Providing official support for linux viewers creates an outsized support load due to users encountering issues getting the viewer to run on their local linux install
• Library Updates - Keeping the libraries up to date requires effort
• Userbase - There are not enough users on linux to justify its upkeep

However, it's been a long time since each of these complaints has been evaluated:

Support Load - An additional officially supported OS would create additional support load. However, compatibility between contemporary linux distros has improved since we stopped publishing a linux build, and in general there are a lot more solid resources, in particular from Valve's work with proton and Steam, for users to use before contacting LL or that we could direct them to. We can also take a different approach when releasing the linux viewer by distributing a plain archive. This would eliminate the expectation that the viewer works with a specific distro, and put some responsibility on distro package maintainers to bottle and prepare the client for users.

Distributing an archive rather than *.deb, *.rpm, et al. would be helpful in that ensuring SL works on specific distros would be left to the people that know those distros best. Speaking as a package maintainer (alpine, arch linux) this is preferred. :)

Library Updates - Since linux support was dropped we've moved 3p library CI/CD to GitHub Actions (GHA.) This means that the entire CI/CD process is transparent and can be contributed to from the open source community. We've already seen a large increase in open source PRs from people interested in restoring linux support. This should reduce the maintenance burden of keeping libraries up to date and compatible with multiple operating systems.

Userbase - I've never bought this argument, because even though the userbase is small the residents on linux are more likely to be the ones contributing back to our open source projects. There's terrific benefit in helping people help us.

General plan

Note: A lot of this work is in progress already (#1099, #1147, #1146)

1. Restore 3p libs - The linux dependencies in autobuild.xml have been left to rot for many years. We need to get newly built versions added, and add linux64 platform support and builds to 3p libs that are missing it.
2. Restore ReleaseOS build Once 3p libs are in better shape, the coderot in the viewer needs to be addressed. This will involve things such as updating SDL to SDL2 so that it is up to date with forks, fixing build scripts, etc.
3. Add GHA builds - Get linux building in GHA CI
4. Package - Set up a basic archive packaging so that the linux viewer can be downloaded from GHA artifacts

LL responsibilities:

After a basic open source configuration is being built and merged into one of our release branches:

1. Set up release build - Set up proprietary build with havok, kdu, fmod, et al.
2. (Maybe) Publish to releasenotes - Set up publication of distribution archives via https://releasenotes.secondlife.com
3. (Maybe) Add viewer to release page - Add the linux platform back to https://secondlife.com/support/downloads/

Tasks

Beta Give feedback

1. Linux viewer (ReleaseOS) resurrection #1099
   c/cpp cmake llcommon llcorehttp llimage llmath llmessage llprimitive llrender llwindow python +11
2. Update Linux media handling #1146
   c/cpp cmake llcommon llplugin python +5
3. Linux GHA builds #1147
   python +1
4. Linux Release configuration

[canny]

This issue has been linked to a Canny post: Linux Viewer 🎉

[nat-goodspeed]

I'm generally in favor of a Linden Linux viewer.

In the past, a few familiar excuses have come up ... add linux64 platform support and builds to 3p libs that are missing it.

What actually caused us to drop Linux support years ago was the project to introduce a 64-bit viewer. I was appalled to discover that some of the Linux 3p repos contained only 32-bit binary libraries (from some already outdated distro version?). I started down the path of trying to build those Linux libraries from source -- but kept having to add repos as I continued discovering more and more unforeseen dependencies -- not to mention autoconf weirdness trying to build the ones I was accumulating. My then boss inferred a whole rabbit warren and made me stop.

There has since been an effort to make the Linux viewer rely on system libraries instead of replicating the whole ecosystem in autobuild land. Hopefully that gets us past what was, at the time, a showstopper obstacle -- not just an excuse.

[brad-linden]

I think we are past it. with the current 3p lib contributions that have gone into maint-b, I have been able to run a full linux64 ReleaseOS build and log in successfully

[Nicky-D]

that some of the Linux 3p repos contained only 32-bit binary libraries (from some already outdated distro version?).

You are not entirely wrong. That was the gtk-atk-pango 3P. I had a source version for Firestorm and I remember you losing a lot of hair over trying to get it to compile on the rather strange LL franken-debian.

That dependency was a mess either way. And got replaced with fltk.

There has since been an effort to make the Linux viewer rely on system libraries instead of replicating the whole ecosystem in autobuild land.

There was for some time the hope to go USE_SYSTEMLIBS, but it never did go anywhere. Then I pulled all that during the cmake renovation.
Though I won't lie about my dislike for autobuild and hope we go conan or vcpk one day. Consuming a lot of third party libs w/o having to curate them as 3P.

[AiraYumi]

I think it's better to organize Linux x86 (non x64) dependencies before the official release.

At least from the viewer.

[AiraYumi]

What would be the proper way to test a Release build?

[AiraYumi]

@kylelinden @brad-linden @nat-goodspeed @Nicky-D As for linux's havok, it doesn't seem to be used even on third-party viewers, so I think it would be a good idea to disable it for now. What do you think?

[nat-goodspeed]

Do Linux viewers not support pathfinding?

[Nicky-D]

Do Linux viewers not support pathfinding?

Not without Havok. Without Havok there is also no mesh upload.
Having no Havok for Linux would be a bummer, maybe not a shoe stopper, but not great either.

[brad-linden]

I think disabling havok and pathfinding to get unblocked is fine. We should file an issue for restoring it in the future. actually we should probably have issues for all of the closed source dependencies other than vivox

[AiraYumi]

Hmm. I don't think there are any major obstacles to including the Linux version of the viewer in the release notes.
It is Maintenance B.
However, since there may be problems that haven't been discovered yet, I think it would be better to include the Linux ReleaseOS in the release notes and get feedback. What do you think?

We hope that by including this in the release notes, we will be able to identify any potential fatal bugs that need to be resolved before the production release.