[opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Which windows command prompt should be used? I have used Developer Command
Prompt for VS2013
which defaults to 32 bit tool set via %comspec% /k ""C:\Program Files
(x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
The C:\Users\Bill\P64\viewer-build-variables\convenience script, at
default, also sets a 32 bit tool set.

So, what terminal should be used for 64 bit? VS2013 x64 Native Tools
Command Prompt sets 64 bit tool sets via
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat"" amd64? Or, will the convenience script set the
system build variables and pick the proper tool set regardless of which
terminal is used?

Next question, what distro and gcc version is being used for linux builds?

On Wed, Nov 23, 2016 at 12:11 PM, Nat Goodspeed <nat at lindenlab.com> wrote:

> On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian <nickyperian at gmail.com>
> wrote:
>
> This is on a Release. The solution defaulted to Debug and I failed to
>> notice.
>> So, that raises the question; Why when autobuild source_environment is
>> set to Release did it not follow through to the soultion?
>>
>
> There is a program called VSTool in indra/tools/vstool that has been used
> to postprocess the .sln file generated by autobuild configure (running
> CMake). We recently stopped running that implicitly, for a couple reasons:
>
>
>    1. VSTool began failing intermittently on our build machines,
>    impacting the reliability of our build farm. But VSTool's only function is
>    to set defaults for the IDE -- which is completely irrelevant to an
>    unattended build! So for an official build-farm build, the only effect of
>    running VSTool was the negative one of introducing intermittent failures.
>    It can take an hour to rerun a full official build-farm build.
>    2. VSTool was being run in a weird way, with '&&' being passed by
>    autobuild.xml as a command argument.
>       - That relied on autobuild invoking commands through the shell.
>       autobuild-1.1 has recently started invoking commands directly
>       *without* using the shell, which in general is more robust and
>       secure. But that meant that '&&' and 'VSTool.exe' and its args were being
>       passed to devenv as additional arguments. Of course devenv was completely
>       nonplussed.
>       - autobuild.xml is not a scripting language. It has no way to
>       invoke VSTool conditionally. We couldn't run it only for interactive
>       developer builds.
>
>
> The *right* fix is for CMake to generate the .sln (etc.) files with the
> appropriate defaults already set.
>
> Until we get that, if your workflow involves autobuild configure followed
> by a Visual Studio IDE session, please run autobuild configure in a shell
> script that also runs VSTool with the arguments you've seen in previous
> versions of autobuild.xml.
>
>
>> Error 7 error LNK1181: cannot open input file
>> '..\llimagej2coj\Release\llimagej2coj.lib' C:\Users\Bill\P64\viewer64\bui
>> ld-vc120-32\newview\LINK secondlife-bin
>> Error 4 error C2039: 'page_zoom_factor' : is not a member of
>> 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind
>> ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef
>> Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such
>> file or directory C:\Users\Bill\P64\viewer64\bui
>> ld-vc120-32\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj
>>
>
> I jumped right in trying to build a 64-bit Windows viewer. Your mail
> prompted me to circle back and clean up the 32-bit Windows build of
> lindenlab/viewer64. I see these errors and am working on them. (I think
> I've already worked around the LLCEFLibSettings one.)
>
> Please stay tuned!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161124/ff38405e/attachment.htm