[opensource-dev] Building the viewer after the latest commits

[Adam Moss]

Hiya,

If someone's re-investigating/rebuilding most of the third-party libraries
anyway...
Isn't it a good time for the SL Linux client to go (probably exclusively)
64-bit?  This wasn't true 8 years ago and wasn't quite true 4 years ago,
but I think on balance it'd be a good and happy move in 2014.

(IIRC several of the libraries used by the viewer are also used by the
servers, which are 64-bit Linux, so there may be *less* work for LL overall
in maintaining these builds, FWIW.)

The 32-bit client is only marginally happy on 64-bit systems despite the
compatibility layers - for example, many of the interesting and
most-relevant-to-SL gstreamer audio/video codec packs on modern distros
*still* install into an non-architecture-specific place, meaning you have
to choose between a 32-bit (SL) or 64-bit (every other app) codec pack
exclusively.

In addition, building the official LL viewer on 64-bit in the absence of
pre-rolled libraries is a fairly gigantuan task with results which are way
off the QA'd path - personally I'll have to stoop to a 32-bit VM to
continue development nowadays if I can work up the courage.

Cheers,
--Adam


On 19 August 2014 16:47, Oz Linden (Scott Lawrence) <oz at lindenlab.com>
wrote:

>  On 2014-08-19, 07:27 , Henri Beauchamp wrote:
>
> On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote:
>
>
>  Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian:
>
>   I ran into an issue with boost built with gcc 4-6 and viewer compiling goo
> 4-7. rebuilt boost on 4.7 and no more problems.
>
>  Hi,
>
> that worked. Now that needs to go into the official sources...
>
>  Hopefully not !...
>
> The current Linux builds of the viewer and pre-built libraries are
> compiled with gcc 4.6, which also imposes a minimal requirement on
> the target systems' libstdc++ version (6.0.16).
>
> If LL were to provide pre-built libraries compiled with gcc v4.7,
> then the "old" (like 2 years old *only*) Linux distributions would
> become incapable of running the resulting viewer.
>
> You should instead keep a partition (or a VirtualBox virtual machine)
> with a build-system matching LL's one (i.e. using gcc 4.6.4 and its
> associated libstdc++).
>
> Henri.
>
>
> I don't want to miss an opportunity to agree with Henri...
>
> At present, our standard Linux build environment for Linux is Debian
> Squeeze, gcc 4.6.  That's what we'll build the packages for. We expect to
> start a toolchain update for Windows (to VS 2013) and Mac OSX (to Xcode 5,
> clang) shortly, but don't plan to change Linux (it was updated much more
> recently than the other platforms as part of the Sunshine project).
>
> You are of course welcome to use what you want for your builds, but we
> won't be making changes to the packages we provide in order to support that.
>
> --
>  *Scott Lawrence* | *Technical Director, Second Life*
> Skype ozlinden | Second Life Oz Linden
> <https://my.secondlife.com/oz.linden>
> Linden Lab | Makers of Shared Creative Spaces <http://lindenlab.com/>
> Check out what we're working on! <http://lindenlab.com/products>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140820/6b27a490/attachment.htm