[opensource-dev] Fwd: 64 bit viewers build instructions

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?

Error 7 error LNK1181: cannot open input file
'..\llimagej2coj\Release\llimagej2coj.lib'
C:\Users\Bill\P64\viewer64\build-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\indra\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\build-vc120-32\packages\include\openjpeg\openjpeg.h
94 1 llimagej2coj

Post by Nicky Perian
Complete the record on opensource-dev.
---------- Forwarded message ----------
Date: Wed, Nov 23, 2016 at 9:13 AM
Subject: Re: 64 bit viewers build instructions
Thanks,
I'm trying to build 32 bit windows first.
These appear library related and since you are active in building them
thought you should know. Likely that you already know but just in case ....
Error 11 error LNK1181: cannot open input file 'vorbisfile_static_d.lib'
C:\Users\Bill\P64\viewer64\build-vc120\newview\LINK secondlife-bin
Error 5 error LNK1181: cannot open input file
'libboost_coroutine-mt-gd.lib' C:\Users\Bill\P64\viewer64\bui
ld-vc120\media_plugins\libvlc\LINK media_plugin_libvlc
Error 9 error LNK1104: cannot open file 'libboost_coroutine-mt-gd.lib'
C:\Users\Bill\P64\viewer64\build-vc120\llplugin\slplugin\LINK SLPlugin
Error 10 error LNK1104: cannot open file 'exception_handler.lib'
C:\Users\Bill\P64\viewer64\build-vc120\win_crash_logger\LINK
windows-crash-logger
Error 6 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\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj

Sorry! I should be able to get you a new public build of
llphysicsextensions_stub.

https://bitbucket.org/lindenlab/viewer64/commits/4838e2cf369
48f911b072a018f68f1be8c54eeba

Nat Goodspeed

2016-11-23 18:11:02 UTC

On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian <***@gmail.com>
wrote:

This is on a Release. The solution defaulted to Debug and I failed to

Post by Nicky Perian
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.

Post by Nicky Perian
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!

Nicky Perian

2016-11-24 19:19:21 UTC

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?

Post by Nicky Perian
This is on a Release. The solution defaulted to Debug and I failed to

Post by Nicky Perian
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
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.

Nat Goodspeed

2016-11-24 22:51:45 UTC

On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian <***@gmail.com> wrote:

Which windows command prompt should be used? I have used Developer Command

Post by Nicky Perian
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?

Please update your autobuild-1.1 from
https://bitbucket.org/lindenlab/autobuild-1.1 . In the last couple days I
pushed a change that makes autobuild build use its --address-size switch,
along with the AUTOBUILD_VSVER environment variable, to set the environment
(notably the PATH) to run the command specified in autobuild.xml.

(It actually looks up the VSnnnCOMNTOOLS environment variable selected by
AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
those variables.)

On a plain prompt on my system, with no vcvarsall.bat active, that permits
me to run either 32-bit or 64-bit builds depending on the --address-size
(-A) switch.

Post by Nicky Perian
Next question, what distro and gcc version is being used for linux builds?

The near-term answer is that we need to be able to build on Debian wheezy
with gcc 4.7.

Our ops team is busily working up Debian jessie images, but that's not yet
available. I don't know off the top of my head what gcc version is the
default on jessie, but for now it's moot.

P.S. I will have a better fix for the llceflib problem, along with a fix
for the openjpeg issues, next week. Happy Thanksgiving!

--
NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN LAB
| Create Virtual Experiences <https://www.lindenlab.com>

Nicky Perian

2016-11-24 23:49:41 UTC

Happy Thanksgiving. @Nat, I really didn't expect an answer until next week,
hoping it was minimal interruption to your Thanksgiving .

My family just finished a wonderful traditional meal, that is, if you can
call possum pie traditional.

Post by Nicky Perian
Which windows command prompt should be used? I have used Developer Command

Please update your autobuild-1.1 from https://bitbucket.org/
lindenlab/autobuild-1.1 . In the last couple days I pushed a change that
makes autobuild build use its --address-size switch, along with the
AUTOBUILD_VSVER environment variable, to set the environment (notably the
PATH) to run the command specified in autobuild.xml.
(It actually looks up the VSnnnCOMNTOOLS environment variable selected by
AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
those variables.)
On a plain prompt on my system, with no vcvarsall.bat active, that permits
me to run either 32-bit or 64-bit builds depending on the --address-size
(-A) switch.

Post by Nicky Perian
Next question, what distro and gcc version is being used for linux builds?

The near-term answer is that we need to be able to build on Debian wheezy
with gcc 4.7.
Our ops team is busily working up Debian jessie images, but that's not yet
available. I don't know off the top of my head what gcc version is the
default on jessie, but for now it's moot.
P.S. I will have a better fix for the llceflib problem, along with a fix
for the openjpeg issues, next week. Happy Thanksgiving!
--
NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN
LAB | Create Virtual Experiences <https://www.lindenlab.com>

Nicky Perian

2016-11-27 04:37:54 UTC

Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64
openjpeg needs work, The lib names in openjpeg.cmake don't match the new
lib names and there is an archive include file issue. Once the include
files are provided then that just opens the box for un-defines at link.

cef flip issues have returned.

week, hoping it was minimal interruption to your Thanksgiving .
My family just finished a wonderful traditional meal, that is, if you can
call possum pie traditional.

Post by 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?

Please update your autobuild-1.1 from https://bitbucket.org/lindenla
b/autobuild-1.1 . In the last couple days I pushed a change that makes
autobuild build use its --address-size switch, along with the
AUTOBUILD_VSVER environment variable, to set the environment (notably the
PATH) to run the command specified in autobuild.xml.
(It actually looks up the VSnnnCOMNTOOLS environment variable selected by
AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
those variables.)
On a plain prompt on my system, with no vcvarsall.bat active, that
permits me to run either 32-bit or 64-bit builds depending on the
--address-size (-A) switch.

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

The near-term answer is that we need to be able to build on Debian wheezy
with gcc 4.7.
Our ops team is busily working up Debian jessie images, but that's not
yet available. I don't know off the top of my head what gcc version is the
default on jessie, but for now it's moot.
P.S. I will have a better fix for the llceflib problem, along with a fix
for the openjpeg issues, next week. Happy Thanksgiving!
--
NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN
LAB | Create Virtual Experiences <https://www.lindenlab.com>

Nat Goodspeed

2016-11-30 02:37:54 UTC

On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian <***@gmail.com>
wrote:

Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64

Post by Nicky Perian
openjpeg needs work, The lib names in openjpeg.cmake don't match the new
lib names and there is an archive include file issue. Once the include
files are provided then that just opens the box for un-defines at link.

Okay, I've rebuilt p64 openjpeg at 1.5.1. The current tip of
lindenlab/viewer64 pulls in that package, and with those changes I get a
clean local windows 32-bit build. (Other platforms still very much up in
the air.)

Post by Nicky Perian
cef flip issues have returned.

My p64 llceflib wasn't actively tracking the production llceflib repo,
sorry. Callum is currently working up a new package for viewer64.

Nicky Perian

2016-11-30 04:11:10 UTC

Thanks, I'll return to poking at it.

I am unable to get a windows 64 bit build environment. A learning issue for
me.
What commands do you use to switch to 64 bit?

Post by Nicky Perian
Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64

Post by Nicky Perian
cef flip issues have returned.

My p64 llceflib wasn't actively tracking the production llceflib repo,
sorry. Callum is currently working up a new package for viewer64.

Nat Goodspeed

2016-11-30 04:30:12 UTC

Post by Nicky Perian
I am unable to get a windows 64 bit build environment. A learning issue

for me.

Post by Nicky Perian
What commands do you use to switch to 64 bit?

I use:

autobuild build --address-size=64

:-)

But I don't yet have a clean 64-bit build on any platform.

Nicky Perian

2016-11-30 13:53:51 UTC

Would this be a good time to fix this warning?

jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
found; restarting link with /LTCG; add /LTCG to the link command line to
improve linker performance

Thanks

Post by Nicky Perian
I am unable to get a windows 64 bit build environment. A learning issue

for me.

Post by Nicky Perian
What commands do you use to switch to 64 bit?

autobuild build --address-size=64
:-)
But I don't yet have a clean 64-bit build on any platform.

Callum Prentice (Callum)

2016-11-30 21:04:32 UTC

I'd like to fix that too.

Is it just a question of add /LTCG to the jpeglib link command? I see
that's done via an nmake makefile and then build via a .sln but I think I
see where to add that command.

Post by Nicky Perian
Would this be a good time to fix this warning?
jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
found; restarting link with /LTCG; add /LTCG to the link command line to
improve linker performance
Thanks

Post by Nicky Perian
I am unable to get a windows 64 bit build environment. A learning issue

for me.

Post by Nicky Perian
What commands do you use to switch to 64 bit?

autobuild build --address-size=64
:-)
But I don't yet have a clean 64-bit build on any platform.

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges

--
CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Nat Goodspeed

2016-11-30 21:11:05 UTC

On Wed, Nov 30, 2016 at 4:04 PM, Callum Prentice (Callum) <
***@lindenlab.com> wrote:

Is it just a question of add /LTCG to the jpeglib link command? I see

Post by Callum Prentice (Callum)
that's done via an nmake makefile and then build via a .sln but I think I
see where to add that command.

I think we decided back when switching to VS 2013 that /GL and /LTCG didn't
add enough value for us to bother with them. I think the expedient fix
would be to remove /GL from jpeglib.

Monty Brandenberg

2016-11-30 23:12:35 UTC

Post by Nat Goodspeed
I think we decided back when switching to VS 2013 that /GL and /LTCG
didn't add enough value for us to bother with them. I think the
expedient fix would be to remove /GL from jpeglib.

I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
in the cmake directory get updated with current options and the
thinking that led to them...

m
--
Monty Brandenberg | Unit of Production
Skype monty.linden | Second Life Monty Linden

Linden Lab | Makers of Shared Creative Spaces
Check out what we're working on!
_______________________________________________
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

Nicky Perian

2016-12-02 15:25:32 UTC

RE: Windows 64 bit cmake identifier.
What cmake variable is going to be used within cmake for branching 32 vs 64
bit builds?

Example FMODEX.cmake.

Friestorm uses if( NOT ND_BUILD64BIT_ARCH ) which is very specific to
their build system.

So, will it be ARCH or ADDRESS_SIZE or a new variable combining these?

Post by Monty Brandenberg

I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
in the cmake directory get updated with current options and the
thinking that led to them...
m
--
Monty Brandenberg | Unit of Production
Skype monty.linden | Second Life Monty Linden
Linden Lab | Makers of Shared Creative Spaces
Check out what we're working on!
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Nicky Perian

2016-12-04 00:18:53 UTC

With:
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log

I get many:

No windows64 configuration found; inheriting windows

But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
bit and it runs.

vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.

This was with viewer64-callum changes merged in.

Attached is the configure log.

Post by Nicky Perian
RE: Windows 64 bit cmake identifier.
What cmake variable is going to be used within cmake for branching 32 vs
64 bit builds?
Example FMODEX.cmake.
Friestorm uses if( NOT ND_BUILD64BIT_ARCH ) which is very specific to
their build system.
So, will it be ARCH or ADDRESS_SIZE or a new variable combining these?

Post by Monty Brandenberg

I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
in the cmake directory get updated with current options and the
thinking that led to them...
m
--
Monty Brandenberg | Unit of Production
Skype monty.linden | Second Life Monty Linden
Linden Lab | Makers of Shared Creative Spaces
Check out what we're working on!
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Nat Goodspeed

2016-12-04 00:35:24 UTC

On Dec 3, 2016 7:18 PM, "Nicky Perian" <***@gmail.com> wrote:

With:
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log

I get many:

No windows64 configuration found; inheriting windows

But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
bit and it runs.

Yes: we've been discussing those messages internally. The viewer's CMake
logic runs autobuild install for each applicable package, and I think the
messages you're seeing are simply from autobuild waking up each time and
reading autobuild.xml. In other words, I believe the message is about the
package_description rather than any of the installables.

We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.

vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.

This was with viewer64-callum changes merged in.

I'm pretty sure Callum disabled VLC too, though perhaps that's only local
so far.

We're really at about the same point! Please bear with us. :-)

Callum Prentice (Callum)

2016-12-04 01:07:48 UTC

Yep - we;re all following along similar tracks by the sound of it Nicky :)

With my latest changes, if I unload the VLC plugin (as you say, that needs
a little work) the build completes - only issue is that some script is
trying to copy fmodex.dll to the right place and not (the correct)
fmodex64.dll (I fixed the third party package).

If I move that DLL manually, the viewer starts and seems to run, as first
glance anyway, pretty normally.

I'll attack the fmodex and vlc issues on Monday.

Post by Nicky Perian
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log
No windows64 configuration found; inheriting windows
But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
bit and it runs.
Yes: we've been discussing those messages internally. The viewer's CMake
logic runs autobuild install for each applicable package, and I think the
messages you're seeing are simply from autobuild waking up each time and
reading autobuild.xml. In other words, I believe the message is about the
package_description rather than any of the installables.
We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.
vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.
This was with viewer64-callum changes merged in.
I'm pretty sure Callum disabled VLC too, though perhaps that's only local
so far.
We're really at about the same point! Please bear with us. :-)
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Nicky Perian

2016-12-04 01:12:31 UTC

*only issue is that some script is trying to copy fmodex.dll to the right
place and not (the correct) fmodex64.dll (I fixed the third party package).*

It's fixed at:
https://bitbucket.org/kokua/viewer64/commits/ca4ffedff48cf4ae29622434567a59f6b010708b

On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
Yep - we;re all following along similar tracks by the sound of it Nicky :)
With my latest changes, if I unload the VLC plugin (as you say, that needs
a little work) the build completes - only issue is that some script is
trying to copy fmodex.dll to the right place and not (the correct)
fmodex64.dll (I fixed the third party package).
If I move that DLL manually, the viewer starts and seems to run, as first
glance anyway, pretty normally.
I'll attack the fmodex and vlc issues on Monday.

Post by Nicky Perian
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log
No windows64 configuration found; inheriting windows
But, build-vc120-64/packages has 64 bit libraries and the viewer builds
64 bit and it runs.
Yes: we've been discussing those messages internally. The viewer's CMake
logic runs autobuild install for each applicable package, and I think the
messages you're seeing are simply from autobuild waking up each time and
reading autobuild.xml. In other words, I believe the message is about the
package_description rather than any of the installables.
We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.
vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.
This was with viewer64-callum changes merged in.
I'm pretty sure Callum disabled VLC too, though perhaps that's only local
so far.
We're really at about the same point! Please bear with us. :-)
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Callum Prentice (Callum)

2016-12-04 01:32:36 UTC

woohoo - thanks nicky.

Post by Nicky Perian
*only issue is that some script is trying to copy fmodex.dll to the right
place and not (the correct) fmodex64.dll (I fixed the third party package).*
https://bitbucket.org/kokua/viewer64/commits/
ca4ffedff48cf4ae29622434567a59f6b010708b
On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
Yep - we;re all following along similar tracks by the sound of it Nicky
:)
With my latest changes, if I unload the VLC plugin (as you say, that
needs a little work) the build completes - only issue is that some script
is trying to copy fmodex.dll to the right place and not (the correct)
fmodex64.dll (I fixed the third party package).
If I move that DLL manually, the viewer starts and seems to run, as first
glance anyway, pretty normally.
I'll attack the fmodex and vlc issues on Monday.

Post by Nicky Perian
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log
No windows64 configuration found; inheriting windows
But, build-vc120-64/packages has 64 bit libraries and the viewer builds
64 bit and it runs.
Yes: we've been discussing those messages internally. The viewer's CMake
logic runs autobuild install for each applicable package, and I think the
messages you're seeing are simply from autobuild waking up each time and
reading autobuild.xml. In other words, I believe the message is about the
package_description rather than any of the installables.
We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.
vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.
This was with viewer64-callum changes merged in.
I'm pretty sure Callum disabled VLC too, though perhaps that's only
local so far.
We're really at about the same point! Please bear with us. :-)
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

--
CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Nicky Perian

2016-12-09 00:07:42 UTC

Fault:
LINK : fatal error LNK1181: cannot open input file 'fmodex_vc.lib'
[C:\Users\Bill\P64\viewer64\build-vc120-64\newview\secondlife-bin.vcxproj]

Possible Correction, Parts of this were in declined Pull Request #4
This is windows only Darwin and Linux will need a similar code.
# HG changeset patch
# User Nicky Perian <***@yahoo.com>
# Date 1480710394 21600
# Fri Dec 02 14:26:34 2016 -0600
# Node ID f70e1917b449af35d719e3a572694c6768d87254
# Parent 290ae1d71523ee22a079421d4fdeee4225a9f7cc
Provide for x64 FMOD ex libraries

diff -r 290ae1d71523 -r f70e1917b449 indra/cmake/Copy3rdPartyLibs.cmake
--- a/indra/cmake/Copy3rdPartyLibs.cmake Wed Dec 07 22:50:25 2016 -0500
+++ b/indra/cmake/Copy3rdPartyLibs.cmake Fri Dec 02 14:26:34 2016 -0600
@@ -43,12 +43,12 @@
)

if (FMODEX)
-
- if(ADDRESS_SIZE EQUAL 32)
+ if (ADDRESS_SIZE EQUAL 32)
set(release_files ${release_files} fmodex.dll)
- else(ADDRESS_SIZE EQUAL 32)
+ elseif (ADDRESS_SIZE EQUAL 64)
set(release_files ${release_files} fmodex64.dll)
- endif(ADDRESS_SIZE EQUAL 32)
+ endif (ADDRESS_SIZE EQUAL 32)
+# set(debug_files ${debug_files} fmodexL.dll)
endif (FMODEX)

#*******************************
diff -r 290ae1d71523 -r f70e1917b449 indra/cmake/FMODEX.cmake
--- a/indra/cmake/FMODEX.cmake Wed Dec 07 22:50:25 2016 -0500
+++ b/indra/cmake/FMODEX.cmake Fri Dec 02 14:26:34 2016 -0600
@@ -26,10 +26,16 @@
include(Prebuilt)
use_prebuilt_binary(fmodex)
if (WINDOWS)
- set(FMODEX_LIBRARY
- debug fmodexL_vc
- optimized fmodex_vc)
- elseif (DARWIN)
+ if (ADDRESS_SIZE EQUAL 32)
+ set(FMODEX_LIBRARY
+ debug fmodexL_vc
+ optimized fmodex_vc)
+ elseif (ADDRESS_SIZE EQUAL 64)
+ set(FMODEX_LIBRARY
+ debug fmodexL64_vc
+ optimized fmodex64_vc)
+ endif (ADDRESS_SIZE EQUAL 32)
+ elseif (DARWIN)
set(FMODEX_LIBRARY
debug fmodexL
optimized fmodex)

On Sat, Dec 3, 2016 at 7:32 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
woohoo - thanks nicky.

Post by Nicky Perian
*only issue is that some script is trying to copy fmodex.dll to the right
place and not (the correct) fmodex64.dll (I fixed the third party package).*
https://bitbucket.org/kokua/viewer64/commits/ca4ffedff48cf4a
e29622434567a59f6b010708b
On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
Yep - we;re all following along similar tracks by the sound of it Nicky
:)
With my latest changes, if I unload the VLC plugin (as you say, that
needs a little work) the build completes - only issue is that some script
is trying to copy fmodex.dll to the right place and not (the correct)
fmodex64.dll (I fixed the third party package).
If I move that DLL manually, the viewer starts and seems to run, as
first glance anyway, pretty normally.
I'll attack the fmodex and vlc issues on Monday.

Post by Nicky Perian
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log
No windows64 configuration found; inheriting windows
But, build-vc120-64/packages has 64 bit libraries and the viewer builds
64 bit and it runs.
Yes: we've been discussing those messages internally. The viewer's
CMake logic runs autobuild install for each applicable package, and I think
the messages you're seeing are simply from autobuild waking up each time
and reading autobuild.xml. In other words, I believe the message is about
the package_description rather than any of the installables.
We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.
vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.
This was with viewer64-callum changes merged in.
I'm pretty sure Callum disabled VLC too, though perhaps that's only
local so far.
We're really at about the same point! Please bear with us. :-)
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Henri Beauchamp

2016-12-09 10:11:41 UTC

Post by Nicky Perian
Possible Correction, Parts of this were in declined Pull Request #4
This is windows only Darwin and Linux will need a similar code.

Not needed for Darwin (the FMOD Ex Darwin library is a fat binary with
both 32 and 64 bits code in it).

For Linux, just add:
elseif (LINUX)
if (ADDRESS_SIZE EQUAL 64)
set(FMODEX_LIBRARY
debug fmodexL64
optimized fmodex64)
else (ADDRESS_SIZE EQUAL 64)
set(FMODEX_LIBRARY
debug fmodexL
optimized fmodex)
endif (ADDRESS_SIZE EQUAL 64)

Henri.
_______________________________________________
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

Nicky Perian

2016-12-15 00:13:20 UTC

macOS with autobuild-1.1

While building my own 64 bit fmodex archive I had an issue with "autobuild
--address-size=64 build".
autobuild would not build a 64 bit variant. Once I added "export
AUTOBUILD_PLATFORM_OVERRIDE='darwin64'" I was able to produce the 64 bit
archive.

I have not repro'ed because once I had the archive I didn't care to go back
through it.

Just an fyi.

Nicky

Post by Henri Beauchamp

Post by Nicky Perian
Possible Correction, Parts of this were in declined Pull Request #4
This is windows only Darwin and Linux will need a similar code.

Not needed for Darwin (the FMOD Ex Darwin library is a fat binary with
both 32 and 64 bits code in it).
elseif (LINUX)
if (ADDRESS_SIZE EQUAL 64)
set(FMODEX_LIBRARY
debug fmodexL64
optimized fmodex64)
else (ADDRESS_SIZE EQUAL 64)
set(FMODEX_LIBRARY
debug fmodexL
optimized fmodex)
endif (ADDRESS_SIZE EQUAL 64)
Henri.
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Nat Goodspeed

2016-12-15 01:56:00 UTC

On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian <***@gmail.com> wrote:

While building my own 64 bit fmodex archive I had an issue with "autobuild

Post by Nicky Perian
--address-size=64 build".
autobuild would not build a 64 bit variant. Once I added "export
AUTOBUILD_PLATFORM_OVERRIDE='darwin64'" I was able to produce the 64 bit
archive.
I have not repro'ed because once I had the archive I didn't care to go
back through it.

Two comments...

First, it appears that autobuild's argument parsing is sensitive to options
before vs. after the subcommand. I always use "autobuild build -A 64",
which works. I don't know why it doesn't work equally well the other way,
but yours is not the first time I've seen a similar complaint.

Second, I'm glad that the fmodex build responded well to the override. Just
last week I had to tweak the build-cmd.sh scripts for both jsoncpp and
breakpad because their build systems were not forwarding the architecture
or address size properly, and the "darwin64" build was still producing
32-bit libraries. I'm not yet convinced that we've seen the last of that
issue; just be aware that that might be the cause of observed problems.

Nicky Perian

2016-12-22 19:24:35 UTC

I have a local repo of
https://bitbucket.org/lindenlab/viewer-build-variables as a sibling of
viewer64.
Just now pulled and updated it.
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
has been set system wide.
Within my configure script (a windows batch file) is autobuild
source_environment and
âautobuild configure....

I configure then open vs2013 and the errors continue as before.

Don't need to pursue til after holidays.

Merry Christmas!!

Nicky

Nat Goodspeed

2016-12-22 20:51:08 UTC

Post by Nicky Perian
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
has been set system wide.
Within my configure script (a windows batch file) is autobuild
source_environment and
autobuild configure....
I configure then open vs2013 and the errors continue as before.

I'll make the CMake logic die with an error if it doesn't see the
LL_BUILD environment variable. That will at least be less obscure than
"unexpected type 'S'", and may help identify the problem you're
encountering.

Post by Nicky Perian
Merry Christmas!!

You too! And to all a good night!
_______________________________________________
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

Nicky Perian

2017-01-05 00:43:14 UTC

Post by Nat Goodspeed
I'll make the CMake logic die with an error if it doesn't see the
LL_BUILD environment variable. That will at least be less obscure than
"unexpected type 'S'", and may help identify the problem you're
encountering.

I'm back. Still with this hiccup.

Nicky

Post by Nicky Perian
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-

variables\variables

Post by Nicky Perian
has been set system wide.
Within my configure script (a windows batch file) is autobuild
source_environment and
autobuild configure....
I configure then open vs2013 and the errors continue as before.

Post by Nicky Perian
Merry Christmas!!

You too! And to all a good night!

Nicky Perian

2017-01-05 04:50:57 UTC

Backed out changeset: 54c80e27a54f restore build switches

Building now.

Did notice other avatars are grey. Mine looks fine.

I'm back. Still with this hiccup.
Nicky

Post by Nicky Perian
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-vari

ables\variables

Post by Nicky Perian
Merry Christmas!!

You too! And to all a good night!

Nat Goodspeed

2017-01-05 19:16:45 UTC

Post by Nat Goodspeed
I'll make the CMake logic die with an error if it doesn't see the

Post by Nat Goodspeed
LL_BUILD environment variable. That will at least be less obscure than
"unexpected type 'S'", and may help identify the problem you're
encountering.

I'm back. Still with this hiccup.

I assert that when LL_BUILD is set during 'autobuild configure', that is,
at the time CMake is run, and when that LL_BUILD value contains at least
"-DLL_WINDOWS=1" (as in
https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default&fileviewer=file-view-default#variables-26),
the "unexpected type 'S'" problem goes away. We observed that problem
ourselves, and that fixed it for us.

Moreover, when AUTOBUILD_VARIABLES_FILE is set to the pathname of a local
clone of the above-linked file at the time you run 'autobuild
source_environment', the output of 'autobuild source_environment' does
contain a command to set LL_BUILD appropriately.

I do not have enough information to know where in your build environment
the disconnect lies.

Nicky Perian

2017-01-05 21:41:39 UTC

Post by Nat Goodspeed
I do not have enough information to know where in your build environment

the disconnect lies.
autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
autobuild --address-size=64 configure -c ReleaseOS --
-DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
-DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1
|c:\cygwin64\bin\tee -a configRel.log
autobuild --verbose --address-size=64 build -c ReleaseOS --no-configure
2>&1 |c:\cygwin64\bin\tee BuildRel.log

Environment after running autobuild source_environment
(autobuild-1.1) C:\Users\Bill\P64\viewer64>env
!::=::\
!C:=C:\Users\Bill\P64\viewer64
!ExitCode=00000000
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Bill\AppData\Roaming
asl.log=Destination=file
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
COMMONPROGRAMFILES=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=BILLAW
COMSPEC=C:\WINDOWS\system32\cmd.exe
DXSDK_DIR=C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\
FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
FPS_BROWSER_USER_PROFILE_STRING=Default
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\Bill
KDS_LANGUAGE=13
LOCALAPPDATA=C:\Users\Bill\AppData\Local
LOGONSERVER=\\BILLAW
NUMBER_OF_PROCESSORS=8
OneDrive=C:\Users\Bill\OneDrive
OS=Windows_NT
PATH=/cygdrive/c/Users/Bill/Envs/autobuild-1.1/Scripts:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program
Files (x86)/Intel/iCLS Client:/cygdrive/c/Program Files/Intel/iCLS
Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program
Files (x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine
Components/IPT:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management
Engine Components/IPT:/cygdrive/c/Program Files (x86)/NVIDIA
Corporation/PhysX/Common:/cygdrive/c/Program
Files/TortoiseHg:/cygdrive/c/Python27:/cygdrive/c/Program Files
(x86)/Windows Kits/8.1/Windows Performance Toolkit:/cygdrive/c/Program
Files/Microsoft SQL Server/110/Tools/Binn:/cygdrive/c/Program Files
(x86)/Microsoft SDKs/TypeScript/1.0:/cygdrive/c/Program Files/Microsoft SQL
Server/120/Tools/Binn:/cygdrive/c/Program Files
(x86)/CMake/bin:/cygdrive/c/Python27/Scripts:/usr/bin:/usr/sbin:/cygdrive/c/Program
Files
(x86)/QuickTime/QTSystem:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/TortoiseGit/bin:/cygdrive/c/Program
Files/doxygen/bin:/cygdrive/c/Program Files (x86)/Midnight
Commander:/cygdrive/c/Users/Bill/AppData/Local/Microsoft/WindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3c03
ProgramData=C:\ProgramData
PROGRAMFILES=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=(autobuild-1.1) $P$G
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SYSTEMDRIVE=C:
SYSTEMROOT=C:\WINDOWS
TEMP=/cygdrive/c/Users/Bill/AppData/Local/Temp
TMP=/cygdrive/c/Users/Bill/AppData/Local/Temp
USERDOMAIN=BILLAW
USERDOMAIN_ROAMINGPROFILE=BILLAW
USERNAME=Bill
USERPROFILE=C:\Users\Bill
VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\
VENV=autobuild-1.1
VIRTUALENVWRAPPER_PROJECT_FILENAME=.project
VIRTUAL_ENV=C:\Users\Bill\Envs\autobuild-1.1
VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\Tools\
VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\Tools\
WINDIR=C:\WINDOWS
WORKON_HOME=C:\Users\Bill\Envs
_OLD_VIRTUAL_PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS
Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\NVIDIA Corporation\PhysX\Common;C:\Program
Files\TortoiseHg;C:\Python27;C:\Program Files (x86)\Windows
Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL
Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft
SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL
Server\120\Tools\Binn\;C:\Program Files
(x86)\CMake\bin;C:\Python27\Scripts;C:\cygwin64\bin;C:\cygwin64\usr\sbin;C:\Program
Files
(x86)\QuickTime\QTSystem\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
Files\TortoiseGit\bin;C:\Program Files\doxygen\bin;C:\Program Files
(x86)\Midnight Commander;C:\Users\Bill\AppData\Local\Microsoft\WindowsApps;
_OLD_VIRTUAL_PROMPT=$P$G
TERM=cygwin
HOME=/home/Bill

(autobuild-1.1) C:\Users\Bill\P64\viewer64>

Post by Nat Goodspeed
I'll make the CMake logic die with an error if it doesn't see the

Post by Nat Goodspeed
LL_BUILD environment variable. That will at least be less obscure than
"unexpected type 'S'", and may help identify the problem you're
encountering.

I'm back. Still with this hiccup.

I assert that when LL_BUILD is set during 'autobuild configure', that is,
at the time CMake is run, and when that LL_BUILD value contains at least
"-DLL_WINDOWS=1" (as in https://bitbucket.org/lindenlab/viewer-build-
variables/src/tip/variables?at=default&fileviewer=file-
view-default#variables-26), the "unexpected type 'S'" problem goes away.
We observed that problem ourselves, and that fixed it for us.
Moreover, when AUTOBUILD_VARIABLES_FILE is set to the pathname of a local
clone of the above-linked file at the time you run 'autobuild
source_environment', the output of 'autobuild source_environment' does
contain a command to set LL_BUILD appropriately.
I do not have enough information to know where in your build environment
the disconnect lies.

Nat Goodspeed

2017-01-05 22:29:07 UTC

Post by Nat Goodspeed
I do not have enough information to know where in your build environment

I could be misinterpreting; you could simply be running the above commands
for purposes of creating this mail message. But if this is the command
sequence you actually use to configure and build, then autobuild
source_environment is not affecting the running environment.

autobuild source_environment does not (cannot) directly modify the parent
shell's environment variables. It simply writes to its stdout a sequence of
variable assignments in bash syntax to be interpreted by the parent shell.

You can achieve that either by something like:

eval "$(autobuild source_environment)"

or something more like:

varsfile="$(mktemp -t vars.XXXXXXXX)"
autobuild source_environment > "$varsfile"
source "$varsfile"

You might consider temporarily adding a command such as:

echo "LL_BUILD = '$LL_BUILD'"

to ensure that the autobuild source_environment command is in fact having
the desired effect.

Nicky Perian

2017-01-06 01:52:13 UTC

I was expecting to build from the windows command prompt. I can go into
Cygwin64 terminal and
eval "$(autobuild source_environment)" appears to run, but doesn't feedback
any information that it has.
Then in the windows command prompt terminal a virtualenv is set to
autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal
the virtualenv is lost and cannot be set and autobuild1.0 fails for no
address-size. From the windows command prompt eval is a cannot find this
program.

I find it disturbing, to say the least, that the total autobuild cannot be
completed from the windows command prompt.

Post by Nat Goodspeed
I do not have enough information to know where in your build environment

I could be misinterpreting; you could simply be running the above commands
for purposes of creating this mail message. But if this is the command
sequence you actually use to configure and build, then autobuild
source_environment is not affecting the running environment.
autobuild source_environment does not (cannot) directly modify the parent
shell's environment variables. It simply writes to its stdout a sequence of
variable assignments in bash syntax to be interpreted by the parent shell.
eval "$(autobuild source_environment)"
varsfile="$(mktemp -t vars.XXXXXXXX)"
autobuild source_environment > "$varsfile"
source "$varsfile"
echo "LL_BUILD = '$LL_BUILD'"
to ensure that the autobuild source_environment command is in fact having
the desired effect.

Nicky Perian

2017-01-06 10:37:21 UTC

Try creating the env file and reading it. Think about how the UNIX

environment works. >The CMD shell and probably even PowerShell won't see it.

I'm thinking the problem is not being able to execute bash internal
commands such as "eval" and "source" from a windows CMD shell. Programs
such as "tee" work OK but can't reach internals. Next try is to make it
work entirely from cygwin64. Just will be some long commands to reach
autobuild-1.1 which will not be a problem once autobuild-1.1 is standard.

Thanks

Try creating the env file and reading it. Think about how the UNIX
environment works. The CMD shell and probably even PowerShell won't see it.
I was expecting to build from the windows command prompt. I can go into
Cygwin64 terminal and
eval "$(autobuild source_environment)" appears to run, but doesn't
feedback any information that it has.
Then in the windows command prompt terminal a virtualenv is set to
autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal
the virtualenv is lost and cannot be set and autobuild1.0 fails for no
address-size. From the windows command prompt eval is a cannot find this
program.
I find it disturbing, to say the least, that the total autobuild cannot be
completed from the windows command prompt.

Post by Nat Goodspeed
I do not have enough information to know where in your build

environment the disconnect lies.
autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
autobuild --address-size=64 configure -c ReleaseOS --
-DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
-DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1
|c:\cygwin64\bin\tee -a configRel.log

I could be misinterpreting; you could simply be running the above
commands for purposes of creating this mail message. But if this is the
command sequence you actually use to configure and build, then autobuild
source_environment is not affecting the running environment.
autobuild source_environment does not (cannot) directly modify the parent
shell's environment variables. It simply writes to its stdout a sequence of
variable assignments in bash syntax to be interpreted by the parent shell.
eval "$(autobuild source_environment)"
varsfile="$(mktemp -t vars.XXXXXXXX)"
autobuild source_environment > "$varsfile"
source "$varsfile"
echo "LL_BUILD = '$LL_BUILD'"
to ensure that the autobuild source_environment command is in fact having
the desired effect.

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Nat Goodspeed

2017-01-06 14:46:31 UTC

On Thu, Jan 5, 2017 at 8:52 PM, Nicky Perian <***@gmail.com> wrote:

I was expecting to build from the windows command prompt. I can go into

Post by Nicky Perian
Cygwin64 terminal and
eval "$(autobuild source_environment)" appears to run, but doesn't
feedback any information that it has.

Running that command performs a bunch of bash variable assignments and
'export' commands. It should result in an enriched environment, but you're
right, the command itself doesn't produce output -- unless the bash switch
'set -x' (shell tracing) is in effect.

Post by Nicky Perian
I find it disturbing, to say the least, that the total autobuild cannot be
completed from the windows command prompt.

Sigh, I'm afraid my reply was off-base. I was looking at the way you were
manually executing autobuild source_environment, which could only have the
effect of producing output to stdout -- in this case, to your log file.

But the fact is that current autobuild 1.1's configure and build commands
internally execute the equivalent of autobuild source_environment to
produce the environment passed to the relevant commands specified in
autobuild.xml.

So *if you want the parent shell script* to see the variables produced by
autobuild source_environment, you must use either the 'eval' construct or
redirect source_environment output to a file and then 'source' that file,
as shown in a previous message.

But 'autobuild configure' and 'autobuild build' will now internally run
'autobuild source_environment' for their own processing. So if you don't
need to see autobuild source_environment variables in the parent shell, you
can skip explicitly running 'autobuild source_environment' altogether.

Digression:
https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default&fileviewer=file-view-default
sets variables of the form LL_BUILD_WINDOWS_RELEASE, etc. for DARWIN and
LINUX and RELWITHDEBINFO. Since autobuild source_environment knows the
current platform, it also emits an abbreviated variable LL_BUILD_RELEASE
with the same value as LL_BUILD_WINDOWS_RELEASE (or whichever platform).
Given the configuration you want to build, it also emits another
abbreviated variable LL_BUILD with the same value as LL_BUILD_RELEASE (or
whichever configuration). You can see this when you run 'autobuild
source_environment -c Release' with AUTOBUILD_VARIABLES_FILE set in your
environment.

What should happen is that autobuild configure will internally run
'autobuild source_environment' for the current platform and build
configuration. Thus the CMake logic specified in the viewer's
autobuild.xml, invoked by 'autobuild configure', should (!) see a non-empty
LL_BUILD variable... if AUTOBUILD_VARIABLES_FILE is visible in the
environment passed to autobuild configure.

When the platform-and-config-appropriate LL_BUILD value (containing e.g.
-DLL_WINDOWS) is passed to the viewer's CMake machinery, CMake will in turn
pass those command-line switches to the compiler:
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/cmake/00-Common.cmake?at=default&fileviewer=file-view-default#00-Common.cmake-21

When indra/llcommon/llpreprocessor.h sees (e.g.) LL_WINDOWS, it #defines
LL_TYPEOF():
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llpreprocessor.h?fileviewer=file-view-default#llpreprocessor.h-195

And it was lack of LL_TYPEOF() that was causing those baffling "unexpected
type 'S'" errors in llunittype.h:
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llunittype.h?fileviewer=file-view-default#llunittype.h-47

If you are still seeing those errors, you might try adding message output
to indra/cmake/00-Common.cmake, something like:

MESSAGE(STATUS "AUTOBUILD_VARIABLES_FILE =
'$ENV{AUTOBUILD_VARIABLES_FILE}'")
MESSAGE(STATUS "LL_BUILD_WINDOWS_RELEASE =
'$ENV{LL_BUILD_WINDOWS_RELEASE}'")
MESSAGE(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'")
MESSAGE(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")

Of course, if you're trying to build RelWithDebInfo instead of Release, try
reporting LL_BUILD_WINDOWS_RELWITHDEBINFO and LL_BUILD_RELWITHDEBINFO
instead of (or as well as) the output above.

Sorry for not explaining this more fully yesterday!

Nicky Perian

2017-01-08 00:32:22 UTC

Snip Variables.cmake
# Switches set here and in 00-Common.cmake must agree with
# https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
# Reading $LL_BUILD is an attempt to directly use those switches.
#message(STATUS "AUTOBUILD_VARIABLES_FILE =
'$ENV{AUTOBUILD_VARIABLES_FILE}'")
#message(STATUS "LL_BUILD_WINDOWS_RELEASE =
'$ENV{LL_BUILD_WINDOWS_RELEASE}'")
#message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'")
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()

Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.

Next,
Copyright (C) Microsoft Corporation. All rights reserved.

cl : Command line warning D9002: ignoring unknown option '/OP'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/O:'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OR'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OE'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OF'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option
'/NODEFAULTLIB:LIBCMT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]

No idea where /O* switches are set but appear to be included in every
*.vcxproj.
'/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
/NODEFAULTLIB:LIBCMT*"

These link switches are set in 00-Common.cmake.

Once removed those warning are no longer listed. This in likely a case of
putting link switches in cl without a pass through. I suspect the '/O*'
switches are link switches also, but grep was of no help finding where they
are set.

Good news is the build completed without the crazy errors encountered
earlier.

Post by Nicky Perian
/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1

/DLL_RLEASE_FOR_DOWNLOAD=1

Post by Nicky Perian
/DNDEBUG

DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the

variable

name changed?

Thank you for pointing that out!
https://bitbucket.org/lindenlab/viewer-build-variables/commits/
a9d6c3061349a14289cffb536320f0aa7bdf472f

Nicky Perian

2017-01-10 01:47:51 UTC

LL list server issue so resending

brute force setting of LL_BUILD environment variable.
There may be a better/smarter way, but it appears to work.
# HG changeset patch
# Date 1483848353 21600
# Sat Jan 07 22:05:53 2017 -0600
# Node ID 7b4fb3c48718213d1cd8c1e6c6dca0d50c95d78e
# Parent 390776087c1d7c83f04af629340839fadfdd0735
Brute force set LL_BUILD based on System name and Build type. If it isn't
set error out of configure.
diff -r 390776087c1d -r 7b4fb3c48718 indra/cmake/Variables.cmake
--- a/indra/cmake/Variables.cmake Mon Dec 19 05:11:36 2016 -0600
+++ b/indra/cmake/Variables.cmake Sat Jan 07 22:05:53 2017 -0600
@@ -12,10 +12,37 @@
# Switches set here and in 00-Common.cmake must agree with
# https://bitbucket.org/lindenlab/viewer-build-
variables/src/tip/variables
# Reading $LL_BUILD is an attempt to directly use those switches.
+if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+ if (CMAKE_BUILD_TYPE MATCHES "Debug")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_DEBUG})
+ elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELWITHDEBINFO})
+ elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
+ endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+ if (CMAKE_BUILD_TYPE MATCHES "Debug")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_DEBUG})
+ elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELWITHDEBINFO})
+ elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELEASE})
+ endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+ if (CMAKE_BUILD_TYPE MATCHES "Debug")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_DEBUG})
+ elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELWITHDEBINFO})
+ elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+ set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELEASE})
+ endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()
-
+#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
# Relative and absolute paths to subtrees.
if(NOT DEFINED ${CMAKE_CURRENT_LIST_FILE}_INCLUDED)

Post by Nicky Perian
Snip Variables.cmake
# Switches set here and in 00-Common.cmake must agree with
# https://bitbucket.org/lindenlab/viewer-build-variables/src/
tip/variables
# Reading $LL_BUILD is an attempt to directly use those switches.
#message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_FILE
}'")
#message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_RELEASE
}'")
#message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'")
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()
Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.
Next,
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002: ignoring unknown option '/OP'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/O:'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OR'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OE'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OF'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option
'/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\bu
ild-vc120-64\llcommon\llcommon.vcxproj]
No idea where /O* switches are set but appear to be included in every
*.vcxproj.
'/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
/NODEFAULTLIB:LIBCMT*"
These link switches are set in 00-Common.cmake.
Once removed those warning are no longer listed. This in likely a case of
putting link switches in cl without a pass through. I suspect the '/O*'
switches are link switches also, but grep was of no help finding where they
are set.
Good news is the build completed without the crazy errors encountered
earlier.

Post by Nicky Perian
/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1

/DLL_RLEASE_FOR_DOWNLOAD=1

Post by Nicky Perian
/DNDEBUG

DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the

variable

name changed?

Thank you for pointing that out!
https://bitbucket.org/lindenlab/viewer-build-variables/commi
ts/a9d6c3061349a14289cffb536320f0aa7bdf472f

Nicky D.

2017-01-10 18:30:09 UTC

Post by Nicky Perian
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()
Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.

Autobuild tries to do this by some machinery in source environment, but it
fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.

https://bitbucket.org/NickyD/viewer-build-variables/commits/cfab877696c6a35af1d80e5d17ea7acfffa6c762

Nicky Perian

2017-01-12 18:55:58 UTC

[Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
world. Terrain and most prim textures are grey. Full bright textures and
my avatar appear normal. Is this the same with KDU? I haven't a KDU license
or I would check myself.

Post by Nicky Perian
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})

Post by Nicky Perian
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()
Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.

Autobuild tries to do this by some machinery in source environment, but it
fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.
https://bitbucket.org/NickyD/viewer-build-variables/commits/
cfab877696c6a35af1d80e5d17ea7acfffa6c762

Callum Prentice (Callum)

2017-01-12 18:59:43 UTC

KDU build here was indistinguishable from the 32bit viewer-release on first
inspection.

Tried both with full cache and cleaned one.

Post by Nicky Perian
[Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
world. Terrain and most prim textures are grey. Full bright textures and
my avatar appear normal. Is this the same with KDU? I haven't a KDU license
or I would check myself.

Post by Nicky Perian
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})

Autobuild tries to do this by some machinery in source environment, but
it fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.
https://bitbucket.org/NickyD/viewer-build-variables/commits/
cfab877696c6a35af1d80e5d17ea7acfffa6c762

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Nicky Perian

2017-01-13 22:01:05 UTC

Does "autobuild uninstall xxxxx" work for autobuild-1.1?

On Thu, Jan 12, 2017 at 12:59 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
KDU build here was indistinguishable from the 32bit viewer-release on
first inspection.
Tried both with full cache and cleaned one.

Post by Nicky Perian
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})

Autobuild tries to do this by some machinery in source environment, but
it fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.
https://bitbucket.org/NickyD/viewer-build-variables/commits/
cfab877696c6a35af1d80e5d17ea7acfffa6c762

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Oz Linden (Scott Lawrence)

2017-01-13 22:04:57 UTC

Post by Nicky Perian
Does "autobuild uninstall xxxxx" work for autobuild-1.1?

as far as we know, yes

Documentation that it doesn't is of course welcome

--
OZ LINDEN | Engineering Director, Second Life
email or hangouts: ***@lindenlab.com <mailto:***@lindenlab.com> | Real
Life: Scott Lawrence
LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>

Nicky Perian

2017-01-13 22:08:01 UTC

Post by Oz Linden (Scott Lawrence)
Documentation that it doesn't is of course welcome

(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall openjpeg
Traceback (most recent call last):
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 151, in run
uninstall_packages(args, installed_filename, args.package, args.dry_run)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 71, in uninstall_packages
installed_file.save()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation))
IOError: [Errno 2] No such file or directory:
'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

On Fri, Jan 13, 2017 at 4:04 PM, Oz Linden (Scott Lawrence) <

Post by Nicky Perian
Does "autobuild uninstall xxxxx" work for autobuild-1.1?
as far as we know, yes
Documentation that it doesn't is of course welcome
--
OZ LINDEN | Engineering Director, Second Life
LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Nicky Perian

2017-01-13 22:24:30 UTC

more...
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size=32
uninstall openjpeg
Traceback (most recent call last):
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 151, in run
uninstall_packages(args, installed_filename, args.package, args.dry_run)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 71, in uninstall_packages
installed_file.save()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation))
IOError: [Errno 2] No such file or directory:
'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Post by Oz Linden (Scott Lawrence)
Documentation that it doesn't is of course welcome

(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall openjpeg
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
line 11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 151, in run
uninstall_packages(args, installed_filename, args.package,
args.dry_run)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
installed_file.save()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
representation))
IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'
On Fri, Jan 13, 2017 at 4:04 PM, Oz Linden (Scott Lawrence) <

Nat Goodspeed

2017-01-13 22:25:26 UTC

On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian <***@gmail.com> wrote:

Does "autobuild uninstall xxxxx" work for autobuild-1.1?
You might have to specify "autobuild uninstall --address-size 64 xxxxx" (or
-A 64) for the autobuild uninstall command to select the correct build
directory.

Nicky Perian

2017-01-13 22:53:52 UTC

and more...

Post by Nat Goodspeed
You might have to specify "autobuild uninstall --address-size 64 xxxxx"

(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.

(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
[-A {32,64}]
{} ...
autobuild: error: invalid choice: 'uninstall' (choose from )

and more .......
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
Traceback (most recent call last):
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 151, in run
uninstall_packages(args, installed_filename, args.package, args.dry_run)
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 71, in uninstall_packages
installed_file.save()
File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation))
IOError: [Errno 2] No such file or directory:
'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Post by Nicky Perian
Does "autobuild uninstall xxxxx" work for autobuild-1.1?
You might have to specify "autobuild uninstall --address-size 64 xxxxx"
(or -A 64) for the autobuild uninstall command to select the correct build
directory.

Nicky Perian

2017-01-14 03:53:51 UTC

Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64
bit is worse.
Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the
same viewer with only openjpeg.dll changed.

Post by Nicky Perian
and more...

Post by Nat Goodspeed
You might have to specify "autobuild uninstall --address-size 64 xxxxx"

(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
[-A {32,64}]
{} ...
autobuild: error: invalid choice: 'uninstall' (choose from )
and more .......
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
line 11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 151, in run
uninstall_packages(args, installed_filename, args.package,
args.dry_run)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
installed_file.save()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
representation))
IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Henri Beauchamp

2017-01-14 09:58:07 UTC

Post by Nicky Perian
Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64
bit is worse.
Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the
same viewer with only openjpeg.dll changed.

There are "fixes" that went into OpenJPEG v1.5 and newer, that break
textures in SL (I posted in this list, long ago, about one such issue).
However v1.5 and v2.0 bring security holes fixes and bug fixes.
That's why I integrated the OpenJPEG v1.4 sources to my viewer (in
indra/libopenjpeg/) and patched these sources with all the fixes I
could find in v1.5 and v2.0 repositories and that are not ruining
texture decoding in SL, as well as with a few more security checks
(potential crash bug fixes) by me.

Feel free to grab the Cool VL Viewer's "libopenjpeg" and integrate it
in your own viewer.

Regards,

Henri.
_______________________________________________
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

Nicky Perian

2017-01-16 11:47:26 UTC

@Nat
https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2

Please take this in and then provide for the updated archives in the
viewer. I also received a report that the missing texture issue is in macOS
when using openjpeg-1.5.1.

Or, if the problem with 1.5.1 is easily corrected....

Post by Nicky Perian
and more...

Post by Nat Goodspeed
You might have to specify "autobuild uninstall --address-size 64 xxxxx"

(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
[-A {32,64}]
{} ...
autobuild: error: invalid choice: 'uninstall' (choose from )
and more .......
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
line 11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 151, in run
uninstall_packages(args, installed_filename, args.package,
args.dry_run)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
installed_file.save()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
representation))
IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Nat Goodspeed

2017-01-17 15:03:06 UTC

Post by Nicky Perian
https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
Please take this in and then provide for the updated archives in the viewer. I also received a report that the missing texture issue is in macOS when using openjpeg-1.5.1.

There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.

However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

Post by Nicky Perian
Or, if the problem with 1.5.1 is easily corrected....

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
_______________________________________________
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

Nicky Perian

2017-01-20 13:53:21 UTC

Moving on to Linux and Linux64.

I noticed there isn't an archive for 3p-mesa for linux64.
The one I have used for building linux64 on Kokua is very old.

http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1-linux64-20081016.tar.bz2

Will this be updated for P64_3p-mesa?

Post by Nicky Perian
and more...

Post by Nat Goodspeed
You might have to specify "autobuild uninstall --address-size 64 xxxxx"

(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
[-A {32,64}]
{} ...
autobuild: error: invalid choice: 'uninstall' (choose from )
and more .......
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
line 11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 151, in run
uninstall_packages(args, installed_filename, args.package,
args.dry_run)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
installed_file.save()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
representation))
IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Nat Goodspeed

2017-01-20 15:55:51 UTC

On Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian <***@gmail.com> wrote:

Moving on to Linux and Linux64.
Now you're breaking trail. For the present, we're focusing on Windows and
Mac.

Post by Nicky Perian
I noticed there isn't an archive for 3p-mesa for linux64.
The one I have used for building linux64 on Kokua is very old.
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1-
linux64-20081016.tar.bz2
Will this be updated for P64_3p-mesa?

Let's talk about plans for Linux at the TPV meeting next week.

Nicky Perian

2017-01-29 03:00:13 UTC

macOS build ?
Am I missing something? I have tried ReleaseOS command line build and cmake
doesn't change to the correct source directory to complete the test compile.

Are macOS command line builds possible at this time?

Post by Nicky Perian
Moving on to Linux and Linux64.
Now you're breaking trail. For the present, we're focusing on Windows and
Mac.

Post by Nicky Perian
I noticed there isn't an archive for 3p-mesa for linux64.
The one I have used for building linux64 on Kokua is very old.
http://s3.amazonaws.com/viewer-source-downloads/install_
pkgs/mesa-6.2.1-linux64-20081016.tar.bz2
Will this be updated for P64_3p-mesa?

Let's talk about plans for Linux at the TPV meeting next week.

Nat Goodspeed

2017-01-30 16:37:22 UTC

On Sat, Jan 28, 2017 at 10:00 PM, Nicky Perian <***@gmail.com>
wrote:

macOS build ?

Post by Nicky Perian
Am I missing something? I have tried ReleaseOS command line build and
cmake doesn't change to the correct source directory to complete the test
compile.
Are macOS command line builds possible at this time?

I think what you're encountering is that there is no longer a 'darwin'
platform in viewer64/autobuild.xml, only 'darwin64'. If you use 'autobuild
configure -A 64' (or leave AUTOBUILD_ADDRSIZE=64 set in your environment)
it should work.

Nicky Perian

2017-02-18 18:33:55 UTC

Any idea why autobuild the looks in the wrong location for
installed-packages.xml?

========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ==========
metadata file name: autobuild-package.xml
built Second Life Viewer version 5.1.0.41141
installed files in installed-packages.xml
no installed files found
(C:\Users\Bill\P64\Kokua-SL-64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)

Post by Nicky Perian
and more...

Post by Nat Goodspeed
You might have to specify "autobuild uninstall --address-size 64 xxxxx"

(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
[-A {32,64}]
{} ...
autobuild: error: invalid choice: 'uninstall' (choose from )
and more .......
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
line 11, in <module>
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 151, in run
uninstall_packages(args, installed_filename, args.package,
args.dry_run)
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
installed_file.save()
File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
representation))
IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

Nat Goodspeed

2017-02-18 21:11:50 UTC

On Feb 18, 2017 1:33 PM, "Nicky Perian" <***@gmail.com> wrote:

Any idea why autobuild the looks in the wrong location for
installed-packages.xml?

========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ==========
metadata file name: autobuild-package.xml
built Second Life Viewer version 5.1.0.41141
installed files in installed-packages.xml
no installed files found (C:\Users\Bill\P64\Kokua-SL-
64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)

The autobuild feature that implicitly expands environment variables such as
$AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and we
probably haven't yet covered all the cases where that should happen.

The initial implementation expanded variables right at the point when
autobuild.xml is read, so the expansions applied EVERYWHERE. That turned
out to be the wrong approach, since a number of autobuild commands rewrite
autobuild.xml. We found, to our dismay, that after any such command, all
the variables had been replaced with the specific value at that moment -
making the parameterization useless.

So now we expand variables in specific subcommands. I'm sure we don't yet
do that everywhere we should.

Nicky Perian

2017-02-21 14:36:28 UTC

Post by Nat Goodspeed
The autobuild feature that implicitly expands environment variables such

as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent,
and we probably haven't yet covered all the cases where that >>should
happen.

As far as i can tell this happens only on 32 bit builds.

Post by Nicky Perian
Any idea why autobuild the looks in the wrong location for
installed-packages.xml?
========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ==========
metadata file name: autobuild-package.xml
built Second Life Viewer version 5.1.0.41141
installed files in installed-packages.xml
no installed files found (C:\Users\Bill\P64\Kokua-SL-64
\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)
The autobuild feature that implicitly expands environment variables such
as $AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and
we probably haven't yet covered all the cases where that should happen.
The initial implementation expanded variables right at the point when
autobuild.xml is read, so the expansions applied EVERYWHERE. That turned
out to be the wrong approach, since a number of autobuild commands rewrite
autobuild.xml. We found, to our dismay, that after any such command, all
the variables had been replaced with the specific value at that moment -
making the parameterization useless.
So now we expand variables in specific subcommands. I'm sure we don't yet
do that everywhere we should.

Nat Goodspeed

2017-02-21 16:45:32 UTC

Post by Nat Goodspeed
The autobuild feature that implicitly expands environment variables such

as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent,
and we probably haven't yet covered all the cases where that >>should
happen.
As far as i can tell this happens only on 32 bit builds.

Um. That's somewhat surprising, as I would expect that either we always
fail to expand $AUTOBUILD_ADDRSIZE regardless of the value of that
variable, or we always expand $AUTOBUILD_ADDRSIZE regardless of the value
of that variable.

But any specific use case -- "With this specific autobuild.xml and this
version of autobuild, I issued this specific autobuild command and got the
following result" -- would be helpful in diagnosing the problem. In fact,
if it goes into a Jira instead of this email thread, it's less likely to
get lost.

Nicky Perian

2017-01-10 01:49:11 UTC

LL list server problem so resending.

Post by Nicky Perian
Snip Variables.cmake
# Switches set here and in 00-Common.cmake must agree with
# https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
# Reading $LL_BUILD is an attempt to directly use those switches.
#message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_
FILE}'")
#message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_
RELEASE}'")
#message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'")
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()
Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.
Next,
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002: ignoring unknown option '/OP'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/O:'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OR'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OE'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OF'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option
'/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\
build-vc120-64\llcommon\llcommon.vcxproj]
No idea where /O* switches are set but appear to be included in every
*.vcxproj.
'/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
/NODEFAULTLIB:LIBCMT*"
These link switches are set in 00-Common.cmake.
Once removed those warning are no longer listed. This in likely a case of
putting link switches in cl without a pass through. I suspect the '/O*'
switches are link switches also, but grep was of no help finding where they
are set.
Good news is the build completed without the crazy errors encountered
earlier.

Post by Nicky Perian
/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1

/DLL_RLEASE_FOR_DOWNLOAD=1

Post by Nicky Perian
/DNDEBUG

DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the

variable

name changed?

Thank you for pointing that out!
https://bitbucket.org/lindenlab/viewer-build-variables/
commits/a9d6c3061349a14289cffb536320f0aa7bdf472f

Nicky Perian

2017-01-06 11:52:30 UTC

test script
#!/bin/bash
varsfile="$(mktemp -t vars.XXXXXXXX)"
autobuild source_environment > "$varsfile"
source "$varsfile"
echo "LL_BUILD = '$LL_BUILD'"

Output
***@BILLAW /cygdrive/c/Users/Bill/P64/viewer64
$ bash buildit.sh
LL_BUILD = ''

$varsfile contents

export AUTOBUILD='C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild'
export AUTOBUILD_WIN_VSPLATFORM='Win32'
export AUTOBUILD_CONFIGURE_ARCH='i386'
export AUTOBUILD_VERSION_STRING='1.1.0'
export AUTOBUILD_WIN_CMAKE_GEN='Visual Studio 12'
export AUTOBUILD_PLATFORM='windows'
LL_BUILD_BASE_MACROS='/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_LINUX_RELWITHDEBINFO='-O0 -g -fPIC -DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_BASE='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32
/D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1
/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_LINUX_RELEASE='-O2 -g -fPIC -DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_DEBUG_SWITCHES='-O0 -g -fPIC'
LL_BUILD_LINUX_RELWITHDEBINFO_MACROS='-DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DARWIN_RELEASE_SWITCHES='-O3 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_POSIX_BASE_MACROS='-DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_LINUX_BASE='-g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_RELEASE_MACROS='/DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1
/DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO
/NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG
/SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_DARWIN_BASE_MACROS='-DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1
/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_DARWIN_RELEASE_MACROS='-DLL_RELEASE=1
-DLL_RELEASE_FOR_DOWNLOAD=1 -DNDEBUG -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_LINUX_RELWITHDEBINFO_SWITCHES='-O0 -g -fPIC'
LL_BUILD_RELEASE_SWITCHES='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_BASE_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DARWIN_DEBUG_MACROS='-D_DEBUG -DLL_DEBUG=1 -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1
/D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_DARWIN_RELWITHDEBINFO_SWITCHES='-O0 -fPIC -gdwarf-2
-stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1
/D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_DARWIN_RELEASE='-O3 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/
-DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DNDEBUG -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELWITHDEBINFO_MACROS='/DLL_RELEASE=1
/DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_DARWIN_RELWITHDEBINFO='-O0 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/
-DLL_RELEASE=1 -DNDEBUG -DLL_RELEASE_WITH_DEBUG_INFO=1 -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELEASE_SWITCHES='/MD /O2 /Ob2 /INCREMENTAL:NO
/OPT:REF /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_RELEASE_SWITCHES='-O2 -g -fPIC'
LL_BUILD_LINUX_RELEASE_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_BASE_SWITCHES='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT'
LL_BUILD_DARWIN_DEBUG_SWITCHES='-O0 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_WINDOWS_BASE_MACROS='/D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELWITHDEBINFO='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t-
/Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
/DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_WINDOWS_BASE_SWITCHES='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_DEBUG_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_RELWITHDEBINFO_MACROS='/DLL_RELEASE=1
/DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_RELEASE='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF /Zc:wchar_t-
/Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
/DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELEASE_MACROS='/DLL_RELEASE=1
/DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_RELWITHDEBINFO='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t- /Zi /GR
/DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
/DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_DARWIN_RELWITHDEBINFO_MACROS='-DLL_RELEASE=1 -DNDEBUG
-DLL_RELEASE_WITH_DEBUG_INFO=1 -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DARWIN_BASE_SWITCHES='-fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_LINUX_DEBUG='-O0 -g -fPIC -DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELEASE='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
/DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0
/D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE
/D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1
/DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_DARWIN_DEBUG='-O0 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/
-D_DEBUG -DLL_DEBUG=1 -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_BASE='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32
/D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_LINUX_BASE_SWITCHES='-g -fPIC'
USE_INCREDIBUILD='0'
LL_BUILD_DARWIN_BASE='-fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/
-DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB
-DLIB_NDOF=1'

set_build_variables() {
# set_build_variables is a dead branch of the evolutionary tree. The
# functionality formerly engaged by the command:
# set_build_variables convenience Release
# has now been subsumed into autobuild source_environment itself.
But
# since a number of build-cmd.sh scripts have been tweaked to call
# set_build_variables, make it produce an explanatory error. While
it
# would be simpler to remove the shell function and produce an error
# that way, that could leave a developer scrambling to figure out:
# okay, this line broke, why? Did set_build_variables go away? Did
its
# name change? What replaces it?
echo "set_build_variables is no longer needed. Pass to autobuild
source_environment
the pathname of your local clone of the build-variables/variables file, or
set
AUTOBUILD_VARIABLES_FILE to that pathname before autobuild
source_environment,
and remove the set_build_variables command. All the same variables will be
set." 1>&2
exit 1
}

# Usage:
# switches="$(remove_switch -DPIC $LL_BUILD)"
# It's important NOT to quote whichever compiler-arguments string you
pass to
# remove_switch (LL_BUILD in the example above), just as it's important
not to
# quote it when passing it to the compiler itself: bash must parse into
# separate tokens.
remove_switch() {
local todel="$1"
shift
local out=()
for sw
do if [ "$sw" != "$todel" ]
then # append $sw to out
out[${#out[*]}]="$sw"
fi
done
echo "${out[@]}"
}

# Usage:
# switches="$(replace_switch -DPIC -DPOC $LL_BUILD)"
# It's important NOT to quote whichever compiler-arguments string you
pass to
# replace_switch (LL_BUILD in the example above), just as it's
important not to
# quote it when passing it to the compiler itself: bash must parse into
# separate tokens.
replace_switch() {
local todel="$1"
local toins="$2"
shift
shift
echo "$toins $(remove_switch "$todel" "$@")"
}

fix_dylib_id() {
local dylib=$1
local dylink="$dylib"
if [ -f "$dylib" ]; then
if [ -L "$dylib" ]; then
dylib="$(readlink "$dylib")"
fi
install_name_tool -id "@executable_path/../Resources/$dylib"
"$dylib"
if [ "$dylib" != "$dylink" ]; then
ln -svf "$dylib" "$dylink"
fi
fi
}

build_sln() {
local solution=$1
local config=$2
local proj="${3:-}"

if (($USE_INCREDIBUILD)) ; then
BuildConsole "$solution" ${proj:+/PRJ="$proj"} /CFG="$config"
else
devenv.com "$(cygpath -w "$solution")" /build "$config"
${proj:+/project "$proj"}
fi
}

# function for loading visual studio related env vars
load_vsvars() {
export DEVENVDIR="C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\IDE"
export EXTENSIONSDKDIR="C:\Program Files (x86)\Microsoft
SDKs\Windows\v8.1\ExtensionSDKs"
export FRAMEWORK40VERSION="v4.0"
export FRAMEWORKDIR="C:\Windows\Microsoft.NET\Framework"
export FRAMEWORKDIR32="C:\Windows\Microsoft.NET\Framework"
export FRAMEWORKVERSION="v4.0.30319"
export FRAMEWORKVERSION32="v4.0.30319"
export FSHARPINSTALLDIR="C:\Program Files (x86)\Microsoft
SDKs\F#\3.1\Framework\v4.0"
export INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows
Kits\8.1\include\shared;C:\Program Files (x86)\Windows
Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;"
export LIB="C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows
Kits\8.1\lib\winv6.3\um\x86;"
export
LIBPATH="C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\Program Files
(x86)\Microsoft Visual Studio 12.0\VC\LIB;C:\Program Files (x86)\Microsoft
Visual Studio 12.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows
Kits\8.1\References\CommonConfiguration\Neutral;C:\Program Files
(x86)\Microsoft
SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0\References\CommonConfiguration\neutral;"
export PATH="/cygdrive/c/Program Files (x86)/Microsoft Visual
Studio
12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/cygdrive/c/Program
Files (x86)/Microsoft SDKs/F#/3.1/Framework/v4.0/:/cygdrive/c/Program Files
(x86)/MSBuild/12.0/bin:/cygdrive/c/Program Files (x86)/Microsoft Visual
Studio 12.0/Common7/IDE/:/cygdrive/c/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/BIN:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio
12.0/Common7/Tools:/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319:/cygdrive/c/Program
Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/cygdrive/c/Program
Files (x86)/HTML Help Workshop:/cygdrive/c/Program Files (x86)/Microsoft
Visual Studio 12.0/Team Tools/Performance Tools:/cygdrive/c/Program Files
(x86)/Windows Kits/8.1/bin/x86:/cygdrive/c/Program Files (x86)/Microsoft
SDKs/Windows/v8.1A/bin/NETFX 4.5.1
Tools/:/cygdrive/c/Users/Bill/Envs/autobuild-1.1/Scripts:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program
Files (x86)/Intel/iCLS Client/:/cygdrive/c/Program Files/Intel/iCLS
Client/:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program
Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program
Files (x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine
Components/IPT:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management
Engine Components/IPT:/cygdrive/c/Program Files (x86)/NVIDIA
Corporation/PhysX/Common:/cygdrive/c/Program
Files/TortoiseHg:/cygdrive/c/Python27:/cygdrive/c/Program Files
(x86)/Windows Kits/8.1/Windows Performance Toolkit/:/cygdrive/c/Program
Files/Microsoft SQL Server/110/Tools/Binn/:/cygdrive/c/Program Files
(x86)/Microsoft SDKs/TypeScript/1.0/:/cygdrive/c/Program Files/Microsoft
SQL Server/120/Tools/Binn/:/cygdrive/c/Program Files
(x86)/CMake/bin:/cygdrive/c/Python27/Scripts:/usr/bin:/usr/sbin:/cygdrive/c/Program
Files
(x86)/QuickTime/QTSystem/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program
Files/TortoiseGit/bin:/cygdrive/c/Program
Files/doxygen/bin:/cygdrive/c/Program Files (x86)/Midnight
Commander:/cygdrive/c/Users/Bill/AppData/Local/Microsoft/WindowsApps::$PATH"
export VCINSTALLDIR="C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC"
export VISUALSTUDIOVERSION="12.0"
export VSINSTALLDIR="C:\Program Files (x86)\Microsoft Visual Studio
12.0"
export WINDOWSSDKDIR="C:\Program Files (x86)\Windows Kits\8.1"
export WINDOWSSDK_EXECUTABLEPATH_X64="C:\Program Files
(x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64"
export WINDOWSSDK_EXECUTABLEPATH_X86="C:\Program Files
(x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools"
}

if ! (($USE_INCREDIBUILD)) ; then
load_vsvars
fi
*********************************************************************

The environment has no LL_BUILD variables.

Post by Nat Goodspeed
I do not have enough information to know where in your build environment

I could be misinterpreting; you could simply be running the above commands
for purposes of creating this mail message. But if this is the command
sequence you actually use to configure and build, then autobuild
source_environment is not affecting the running environment.
autobuild source_environment does not (cannot) directly modify the parent
shell's environment variables. It simply writes to its stdout a sequence of
variable assignments in bash syntax to be interpreted by the parent shell.
eval "$(autobuild source_environment)"
varsfile="$(mktemp -t vars.XXXXXXXX)"
autobuild source_environment > "$varsfile"
source "$varsfile"
echo "LL_BUILD = '$LL_BUILD'"
to ensure that the autobuild source_environment command is in fact having
the desired effect.

Henri Beauchamp

2016-12-04 10:02:32 UTC

Post by Nicky Perian
*only issue is that some script is trying to copy fmodex.dll

Speaking of FMOD Ex, you might want to update it. The current version
is v4.44.64 and got crash fixes over the one you are using...

Henri.
_______________________________________________
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

Nicky Perian

2016-11-30 21:48:26 UTC

Post by Callum Prentice (Callum)

Post by Callum Prentice (Callum)
Is it just a question of add /LTCG to the jpeglib link command?

I tired that and it didn't change anything.

On Wed, Nov 30, 2016 at 3:04 PM, Callum Prentice (Callum) <

Post by Callum Prentice (Callum)
I'd like to fix that too.
Is it just a question of add /LTCG to the jpeglib link command? I see
that's done via an nmake makefile and then build via a .sln but I think I
see where to add that command.

Post by Callum Prentice (Callum)
Would this be a good time to fix this warning?
jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
found; restarting link with /LTCG; add /LTCG to the link command line to
improve linker performance
Thanks

Post by Nicky Perian
I am unable to get a windows 64 bit build environment. A learning

issue for me.

Post by Nicky Perian
What commands do you use to switch to 64 bit?

autobuild build --address-size=64
:-)
But I don't yet have a clean 64-bit build on any platform.

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Nicky Perian

2016-11-30 21:52:55 UTC

Disregard, It was a viewer cmake for llimagej2coj
that did not work.

${OPENJPEG_LIBRARIES}
)
+if (WINDOWS)
+ set_target_properties(
+ llimagej2coj
+ PROPERTIES
+ LINK_FLAGS "/MANIFEST:NO /SAFESEH:NO /LTCG /NODEFAULTLIB:LIBCMT"
+ LINK_FLAGS_DEBUG "/MANIFEST:NO /SAFESEH:NO /NODEFAULTLIB:LIBCMTD"
+ )
+endif (WINDOWS)
\ No newline at end of file

Post by Callum Prentice (Callum)

Post by Callum Prentice (Callum)
Is it just a question of add /LTCG to the jpeglib link command?

I tired that and it didn't change anything.
On Wed, Nov 30, 2016 at 3:04 PM, Callum Prentice (Callum) <

Post by Nicky Perian
I am unable to get a windows 64 bit build environment. A learning

issue for me.

Post by Nicky Perian
What commands do you use to switch to 64 bit?

autobuild build --address-size=64
:-)
But I don't yet have a clean 64-bit build on any platform.

_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges

--
CALLUM PRENTICE | Software Engineer
LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>

Cinder Roxley

2017-01-17 15:14:05 UTC

Weâve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can put together some patches to get it working.

--Â
Cinder Roxley
Sent with Airmail

Post by Nicky Perian
Or, if the problem with 1.5.1 is easily corrected....

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load

texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
_______________________________________________
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

Nicky Perian

2017-01-17 17:09:21 UTC

Post by Cinder Roxley

Post by Nat Goodspeed
Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
texture files that are correctly handled by 1.5.0?

Yes.
openjpeg-1.5.1 has so many textures marked as over-sized and unavailable
that the viewer is unusable. This came about with viewer64 as the default
viewer is still on openjpeg-1.4.0. I had seen the same texture missing
message once while using Project Alex Ivy viewer and filed a jira on that
instance at https://jira.secondlife.com/browse/BUG-41228 . I am making a
wild guess, but I think there is a possible CDN delivery issue that
openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU.

I had not known of openjpeg-1.5.0 every being supplied in a viewer or I
would have certainly looked for it.

Post by Cinder Roxley
Weâve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can
put together some patches to get it working.
--
Cinder Roxley
Sent with Airmail

Post by Nat Goodspeed
https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
Please take this in and then provide for the updated archives in the

viewer. I also received a report that the missing texture issue is in macOS
when using openjpeg-1.5.1.
There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.
However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

Post by Nat Goodspeed
Or, if the problem with 1.5.1 is easily corrected....

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
texture files that are correctly handled by 1.5.0?
I think Cinder has a point: if we can move forward with 1.5.1, we should.
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Niran

2017-01-17 17:16:13 UTC

I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all
that better... it was... unreliable.