Re: [opensource-dev] Cygwin64

[Nicky Perian]

updated:
Malwarebytes
Cygwin64
All good now.

On Tue, Jan 28, 2020 at 2:39 PM Nicky Perian  wrote:

> I use Malwarebytes and just had to add a pass exception / exemption for
> c:\Cygwin64 in order to get a good config and build.
>
> Just passing along in case others have the same issue. All worked fine
> yesterday.
>
>
___
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

[opensource-dev] Cygwin64

[Nicky Perian]

I use Malwarebytes and just had to add a pass exception / exemption for
c:\Cygwin64 in order to get a good config and build.

Just passing along in case others have the same issue. All worked fine
yesterday.
___
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

Re: [opensource-dev] INTEL driver windows exit graphics corruption

[Nicky Perian]

Thanks Whirly,

> On Aug 21, 2019, at 5:30 AM, Whirly Fizzle  wrote:
> 
> As far as I'm aware, there isn't a bug that causes graphics corruption when 
> exiting an SL viewer that specifically affects Intel cards.
> 
> I suspect you are looking for this bug, where the problem started with the 
> Windows 10 1903 update - this affects all graphics - Intel, AMD & Nvidia.
> BUG-227042 - When exiting the LL SL viewer graphics are borked 
> <https://jira.secondlife.com/browse/BUG-227042>
> 
> An affected user can fix the corrupted display after exiting an SL viewer by 
> using the shortcut CTRL+SHIFT+WIN+B, which resets the graphics adapter.
> 
> LL shipped a fix for this bug in their Rainbow viewer.
> If Kokua is affected by this bug, you need to merge in this fix: 
> https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/5f073ce21cc1 
> <https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/5f073ce21cc1>
> This fix also fixes this older issue that only affected Nvidia cards as far 
> as I'm aware: BUG-202704 - Corrupted display after closing the viewer with 
> Windows 10 "Night Light" enabled 
> <https://jira.secondlife.com/browse/BUG-202704>
> 
> Regarding something specific to Intel for this bug, maybe you are looking for 
> this?
> https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/ab2ec5c5423b 
> <https://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/ab2ec5c5423b>
> 
> I can't see SL-11341, but it's listed in the Rainbow Viewer release notes as 
> a crash fix: SL-11341 <https://jira.secondlife.com/browse/SL-11341> BugSplat 
> Crash: ig7icd32+0x2b07d
> https://releasenotes.secondlife.com/viewer/6.2.3.527758.html 
> <https://releasenotes.secondlife.com/viewer/6.2.3.527758.html>
> 
> 
> From: opensource-dev-boun...@lists.secondlife.com 
>  on behalf of Nicky Perian 
> 
> Sent: 21 August 2019 01:47
> To: OpenSource Mailing List 
> Subject: [opensource-dev] INTEL driver windows exit graphics corruption
>  
> I saw this documented somewhere. I can't recall where. Does anyone know where?

___
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

[opensource-dev] INTEL driver windows exit graphics corruption

[Nicky Perian]

I saw this documented somewhere. I can't recall where. Does anyone know
where?
___
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

[opensource-dev] LL_TESTS:BOOL=ON

[Nicky Perian]

This is a Kokua viewer question but, should  apply to other third party
viewers and to LL's viewer-release once Linux is re-implemented.

Note: all tests pass on MacOs and VS2013.

Kokua's branch with no rlv is used as it is closest to viewer-release code.

My approach is to use skip(..) to bypass tests that do not work on a linux
build then once the viewer builds go back an attack each skipped test one
by one.

Test:
Building CXX object
llcorehttp/CMakeFiles/INTEGRATION_TEST_llcorehttp.dir/tests/test_allocator.cpp.o
Faiis with:

home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp: In
function ‘void* operator new(std::size_t)’:
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:51:47:
error: declaration of ‘void* operator new(std::size_t) throw
(std::bad_alloc)’ has a different exception specifier
 #define THROW_BAD_ALLOC() throw(std::bad_alloc)
   ^
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:155:39:
note: in expansion of macro ‘THROW_BAD_ALLOC’
 void * operator new(std::size_t size) THROW_BAD_ALLOC()
   ^
In file included from
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:27:0:
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.h:40:8:
error: from previous declaration ‘void* operator new(std::size_t)’
 void * operator new(std::size_t size) throw (std::bad_alloc);
^
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:51:47:
error: declaration of ‘void* operator new [](std::size_t) throw
(std::bad_alloc)’ has a different exception specifier
 #define THROW_BAD_ALLOC() throw(std::bad_alloc)
   ^
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:161:41:
note: in expansion of macro ‘THROW_BAD_ALLOC’
 void * operator new[](std::size_t size) THROW_BAD_ALLOC()
 ^
In file included from
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.cpp:27:0:
/home/bill/kokua-sl-np-sandbox/indra/llcorehttp/tests/test_allocator.h:41:8:
error: from previous declaration ‘void* operator new [](std::size_t)’
 void * operator new[](std::size_t size) throw (std::bad_alloc);
^
The code for this test is the same as what is in viewer-release.

Distribution: gcc (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010

My thought was that MARCO expansion had changed with -c++11 or between
gcc-4.6 and 5.5.

Bottom line is, I need help.

Nicky
___
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

[opensource-dev] Last linux 3p-vlc-bin

[Nicky Perian]

https://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-vlc-bin/rev/315283/arch/Linux/vlc_bin-2.2.3-linux-201606011750-r10.tar.bz2

Can this LL build id 315283 be identified to node from which it was built?
___
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

[opensource-dev] Linux Command Line run with out package

[Nicky Perian]

On windows the viewer can be built with _DPACKAGE:BOOL=OFF then with the 
short-cut properties Start in set to C:\Program 
Files\viewer-release\indra\newview;
you can then start the viewer.

I don’t recall how that is done with  linux build.

I think it is done with parameter passing.

Can someone refresh my memory?

Thanks,
Nicky

___
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

Re: [opensource-dev] Mac Build - Where do I start?

[Nicky Perian]

Step 1.
hg clone ssh://h...@bitbucket.org/lindenlab/viewer-build-variables 


Or
hg clone ssh://h...@bitbucket.org/kokua/viewer-build-variables 
  //setup for multiple 
Xcode installed in /Xcode  currently Xcode-9.3

Set an environment variable 
AUTOBUILD_VARIABLES_FILE=/Users/bill/viewer-build-variables/variables

Step 2.
Pip install autobuild1.1 

Following is a bit customized. I switch between autobuild-1.0 and 
autobuild-1.1. I source .bash_profile for part of the switching.

{code}
# araxis
export PATH=$PATH:/Applications/Araxis\ Merge.app/Contents/Utilities
# virtualenv
export WORKON_HOME=~/virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
# autobuild
#workon autobuild-1.1
#alias autobuild="/Users/bill/virtualenvs/autobuild-1.1/bin/autobuild"
#export AUTOBUILD="/Users/bill/virtualenvs/autobuild-1.1/bin/autobuild"
export AUTOBUILD_VARIABLES_FILE="/Users/bill/viewer-build-variables/variables"
#export PATH='/Library/Python/2.7/site-packages/autobuild:$PATHworkon
export DEVELOPER_DIR='/Xcode/Xcode_9.3.app/Contents/Developer/'
export 
CMAKE_OSX_ROOT='Xcode/Xcode_9.3.app/Contents/Developer/Platforms/MacOSX.platform/Devloper/SDKs/MacOSX10.13.sdk'
{/code}

I source another file to move to older Xcode and autobuild-1.0


Step 3.
Configure and build.

From my build script. Full paths are not needed for CL entry 
{code}
/Users/bill/virtualenvs/autobuild-1.1/bin/autobuild \
configure --address-size=64 -q -c ReleaseOS --   -DLL_TESTS:BOOL=OFF 
-DFMODEX:BOOL=ON -DOPENAL:BOOL=OFF -DPACKAGE:BOOL=ON  \
-DUSE_KDU:BOOL=OFF -DRELEASE_CRASH_REPORTING:BOOL=OFF -DVIEWER_CHANNEL="Kokua 
Release RLV”
…
/Users/bill/virtualenvs/autobuild-1.1/bin/autobuild build --address-size=64 
--no-configure -q -c ReleaseOS 2>&1 |tee -a DarwinSLRLV.log
date 2>&1 |tee -a DarwinSLRLV.log
{/code}







> On Apr 23, 2018, at 9:56 AM, Cinder Roxley  wrote:
> 
> I was looking into this a bit over the weekend. I hadn’t really tried to 
> build SLViewer in a while. I wish I had better news, but I couldn’t figure 
> out what was going on with it now either. Seems to have become a massively 
> over engineered and undocumented process developed for CI not individual 
> development, no doubt. Doesn’t help that autobuiild.xml was removed and 
> recreated making hg blame useless.
> 
> Some docs would be nice, until then, I don’t think figuring it out is worth 
> the time. Sorry.
> 
> On April 20, 2018 at 1:23:40 PM, Kittin Ninetails (kittin.nineta...@gmail.com 
> ) wrote:
> 
>> Hiya,
>> 
>>  
>> I’m snagged.  Very snagged.   First, it complains about a LL_BUILD env var I 
>> don’t have set.  So I set it to -Wall and I get “must contain -isysroot or 
>> something like that.  So I add that, and still no luck.
>> 
>>  
>> I don’t know why automake.xml keeps calling for ../indra when indra is a 
>> subdir of the current directory.
>> 
>>  
>> It’s all very confusing right now and none of the current documents seem to 
>> mention any of this.
>> 
>>  
> ___
> 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

___
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

[opensource-dev] Linux 64 build

[Nicky Perian]

Has anyone seen this before and know how to resolve it?

[  5%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llallocator.cpp.o
In file included from 
/usr/include/x86_64-linux-gnu/c++/6/bits/c++config.h:507:0,
 from /usr/include/c++/6/cstring:41,
 from 
/home/nicky/kokua-sl-gcc6/indra/llcommon/linden_common.h:50,
 from 
/home/nicky/kokua-sl-gcc6/indra/llcommon/llallocator.cpp:27:
/usr/include/x86_64-linux-gnu/c++/6/bits/os_defines.h:44:19: error: missing 
binary operator before token "("
 #if __GLIBC_PREREQ(2,15) && defined(_GNU_SOURCE)

___
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

[opensource-dev] llbase

[Nicky Perian]

package llbase has no installation information configured for platform linux64

What is the correction for this?
___
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

Re: [opensource-dev] building a viewer: fails with some undefined variables

[Nicky Perian]

Repo is not pretty, but is up to date for linux 64 build


> On Mar 31, 2018, at 5:07 PM, Nicky Perian <nickyper...@gmail.com> wrote:
> 
> openjpeg-1.5.0.201701152240-windows64-201701152240.tar.bz2 
> <https://bitbucket.org/kokua/p64_3p-openjpeg/downloads/openjpeg-1.5.0.201701152240-windows64-201701152240.tar.bz2>
> 
> The build code for linux is lacking some pushes. 
> 
> overview <https://bitbucket.org/kokua/p64_3p-openjpeg/overview>
> 
> I’ll have it current in a day or so. Just put a watch on the repo.
> 
>> On Mar 31, 2018, at 4:58 PM, Lance Corrimal <lance.corri...@eregion.de 
>> <mailto:lance.corri...@eregion.de>> wrote:
>> 
>> Am Samstag, 31. März 2018, 20:35:06 CEST schrieb Lance Corrimal:
>>> Am Samstag, 31. März 2018, 19:57:50 CEST schrieb Nicky Perian:
>>>> Yes openjpeg-1.5.1  is faulty.
>>>> openjpeg-1.5.0.180801725-linux64-180801725.tar.bz2
>>>> <https://bitbucket.org/kokua/p64_3p-openjpeg/downloads/openjpeg-1.5.0.1808 
>>>> <https://bitbucket.org/kokua/p64_3p-openjpeg/downloads/openjpeg-1.5.0.1808>
>>>> 0
>>>> 1725-linux64-180801725.tar.bz2>. untested but win and mac versions work.
>>> 
>>> I'll build using that one and report back.
>> 
>> that works fine now, thanks!
>> 
>> could you pass me the link for the windows64 package too?
>> 
>> Cheers
>> LC
>> 
>> 
>> 
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev 
>> <http://wiki.secondlife.com/wiki/OpenSource-Dev>
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
> 

___
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

Re: [opensource-dev] building a viewer: fails with some undefined variables

[Nicky Perian]

openjpeg-1.5.0.201701152240-windows64-201701152240.tar.bz2 
<https://bitbucket.org/kokua/p64_3p-openjpeg/downloads/openjpeg-1.5.0.201701152240-windows64-201701152240.tar.bz2>

The build code for linux is lacking some pushes. 

overview <https://bitbucket.org/kokua/p64_3p-openjpeg/overview>

I’ll have it current in a day or so. Just put a watch on the repo.

> On Mar 31, 2018, at 4:58 PM, Lance Corrimal <lance.corri...@eregion.de> wrote:
> 
> Am Samstag, 31. März 2018, 20:35:06 CEST schrieb Lance Corrimal:
>> Am Samstag, 31. März 2018, 19:57:50 CEST schrieb Nicky Perian:
>>> Yes openjpeg-1.5.1  is faulty.
>>> openjpeg-1.5.0.180801725-linux64-180801725.tar.bz2
>>> <https://bitbucket.org/kokua/p64_3p-openjpeg/downloads/openjpeg-1.5.0.1808
>>> 0
>>> 1725-linux64-180801725.tar.bz2>. untested but win and mac versions work.
>> 
>> I'll build using that one and report back.
> 
> that works fine now, thanks!
> 
> could you pass me the link for the windows64 package too?
> 
> Cheers
> LC
> 
> 
> 
> ___
> 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

___
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

Re: [opensource-dev] building a viewer: fails with some undefined variables

[Nicky Perian]

Yes openjpeg-1.5.1  is faulty. 
openjpeg-1.5.0.180801725-linux64-180801725.tar.bz2 
.
 untested but win and mac versions work.
Please publish what you have done.



> On Mar 31, 2018, at 12:46 PM, Lance Corrimal  
> wrote:
> 
> ok so I've managed to build a viewer now, but when I log in using that viewer 
> no textures are loading. Everything stays grey.
> 
> Any ideas?
> 
> 
> Cheers
> LC
> 
> Am Samstag, 31. März 2018, 15:20:50 CEST schrieb Lance Corrimal:
>> Am Samstag, 31. März 2018, 15:02:28 CEST schrieb Henri Beauchamp:
>>> On Sat, 31 Mar 2018 13:36:28 +0200, Lance Corrimal wrote:
 Hi guys,
 
 I'm trying to build a viewer on linux, and the build fails due to
 several
 undefined variables, which, given their names, should actually be
 defined
 
 somewhere in the source, or in the autobuild_variables_file:
  error: #error "LL_ALIGN_PREFIX and LL_ALIGN_POSTFIX undefined"
  error: 'LL_DEFAULT_HEAP_ALIGN' was not declared in this scope
 
 happens right after the actual build starts.
 
 Where do I get those variables?
>>> 
>>> $ grep -r LL_ALIGN_POSTFIX linden/indra/* | grep '#define'
>>> 
>>> linden/indra/llcommon/llmemory.h:#define LL_ALIGN_POSTFIX(x)
>>> __attribute__((aligned(x))) linden/indra/llcommon/llmemory.h:#define
>>> LL_ALIGN_POSTFIX(x)
>>> linden/indra/llcommon/llmemory.h:#define LL_ALIGN_16(var)
>>> LL_ALIGN_PREFIX(16) var LL_ALIGN_POSTFIX(16)
>>> 
>>> You probably failed to #include "llmemory.h" in the sources where this
>>> error happens.
>> 
>> ...the interesting part here is that I haven't even made any changes yet...
>> and the first time the error hits is actually *inside* llmemory.h:
>> 
>> /home/abuild/rpmbuild/BUILD/phoenix-firestorm-lgpl/indra/llcommon/llmemory.h
>> : 98:2: error: #error "LL_ALIGN_PREFIX and LL_ALIGN_POSTFIX undefined" [ 
>> 286s]  #error "LL_ALIGN_PREFIX and LL_ALIGN_POSTFIX undefined"
>> [  286s]   ^
>> 
>> After closer inspection it seems that LL_LINUX, LL_DARWIN or LL_WINDOWS need
>> to be defined to get the right things done right in the include files...
>> shouldn't autobuild make sure of this?
>> 
>> Cheers
>> LC
> 
> 
> 
> 
> ___
> 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

___
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

Re: [opensource-dev] building a viewer: fails with some undefined variables

[Nicky Perian]

I am limbing along building Kokua on linux with autobuild. If you want you may 
use my viewer-build-variables repo that has some linux adds. This is a WIP.

viewer-build-variables  

> On Mar 31, 2018, at 8:43 AM, Henri Beauchamp  wrote:
> 
> On Sat, 31 Mar 2018 15:20:50 +0200, Lance Corrimal wrote:
> 
>> After closer inspection it seems that LL_LINUX, LL_DARWIN or LL_WINDOWS
>> need to be defined to get the right things done right in the include
>> files... shouldn't autobuild make sure of this?
> 
> I don't use autobuild for my viewer (its build system is "stand alone"
> and derived from Snowglobe's). All you have to do to build a Linux
> binary of the Cool VL Viewer is to point a terminal in linden/indra/
> and type "./buildlinux.sh"... I wish building LL's viewer was just
> as simple.
> 
> But these defines used to be added from indra/cmake/00-Common.cmake
> where you could find lines such as:
> 
> if (LINUX)
>  .../...
>  add_definitions(-DLL_LINUX=1 -D_REENTRANT)
>  .../...
> endif (LINUX)
> 
> and the equivalent for Windows and Darwin.
> 
> You could simply re-add the 'add_definitions(-DLL_=1)' lines in
> 00-Common.cmake...
> 
> 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

___
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

[opensource-dev] Linux viewer manage

[Nicky Perian]

http://s3-proxy.lindenlab.com/private-builds-secondlife-com/ct2/3428/8686/viewer_manager-1.0-linux-503417.tar.bz2
 


Please public this. Just need to get past configure. 

I know it will likely never be used. I want to keep as many files matching as 
possible.


___
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

Re: [opensource-dev] CDN

[Nicky Perian]

I just did a search of SL jira for the word 'cloud' and was returned 571
entries.
The vast majority of these were resolved as Contact Support.
I have a couple questions.
What are the geographic locations of these jira and/or support tickets?
Hint: Pareto graph by location.
What is Support doing to resolve them?




On Fri, Mar 23, 2018 at 5:04 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> If you have an asset in inventory delivered via cdn how is it not in
> inventory?  Is that just a distinction as to the different back-end
> services?
>
> On Fri, Mar 23, 2018 at 4:56 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
>> Ok, Thanks.
>>
>> On Fri, Mar 23, 2018 at 4:55 PM, Oz Linden (Scott Lawrence) <
>> o...@lindenlab.com> wrote:
>>
>>> On 2018-03-23 17:48 , Nicky Perian wrote:
>>>
>>> There Body parts are not updating, Mainly shapes. There was a change put
>>> in a 4-6 months ago to halt inventory updates until body parts where all
>>> in. The shape doesn't update and that prevents more inventory update and
>>> everything stops. The avi remains clouded and none of the prim textures
>>> arrive.
>>>
>>> If it's loading the inventory that's not completing, that's not the CDN
>>> - inventory requests don't go through the CDN.
>>> --
>>> OZ LINDEN | Senior Director, Second Life Engineering
>>> email or hangouts: o...@lindenlab.com | Real Life: Scott Lawrence
>>> LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>
>>>
>>
>>
>
___
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

[opensource-dev] Libraries -- Linux

[Nicky Perian]

I am in process of rebuilding all linux libraries. I had in 2015 broken apart 
gtk-atk-pango-glib into individual autobuild 3p type repositories. 
 
All of those have performed well in Kokua linux and linux64.

I have updated and rebuilt for lack of better terminology, feeder libraries:

I have an issue with fontconfig. I cannot isolate freetype from the system 
version and have during configure 

***

No package 'freetype2' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables FREETYPE_CFLAGS
and FREETYPE_LIBS to avoid the need to call pkg-config.

*

If system package libfreetpye6-dev is present it finds it, but the system 
version is older than what fontconfig wants for minimum required.

I have tried the export of FREETYPE_CFLAGS and FREETYPE_LIBS pointing to 
3p-fontconfig/stage/packages/freetype and the same error occurs.


I need some advice on how to sandbox freetype in the fontconfig build?


Fyi, there is an issue for freetype linux section that is corrected by 

Adding:
mkdir -p "$stage/include/freetype2/"
cp -a include/ft2build.h "$stage/include/"
cp -a include/freetype "$stage/include/freetype2/"

Just before 
make distclean

This same change was placed by Nat in the windows section.___
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

Re: [opensource-dev] Linux

[Nicky Perian]

> Stretch has neither gcc-4.9 nor libpngl2. Both of these are in jessie. Adding 
> wheezy to sources.list then apt-get update and apt-get install will place 
> these in stretch then, comment out the lines about jessie in sources.list and 
> apt-get update again. Don’t  apt-get upgrade with the wheezy lines active.  
> Building non Alex Ivy code went fine with this setup.

Should be Jessie!!!


> On Feb 2, 2018, at 1:33 PM, Nicky Perian <nickyper...@gmail.com> wrote:
> 
> Having read the comments on viewer-release repo and your comment concerning 
> ABI mismatch I want to submit the following:
> 
> I have put together in a VM Debian / stretch. My past linux builds have been 
> on Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9.
> 
> Stretch has neither gcc-4.9 nor libpngl2. Both of these are in wheezy. Adding 
> wheezy to sources.list then apt-get update and apt-get install will place 
> these in stretch then, comment out the lines about wheezy in sources.list and 
> apt-get update again. Don’t  apt-get upgrade with the wheezy lines active.  
> Building non Alex Ivy code went fine with this setup.
> 
> Ubuntu is a good choice also and has the advantage of being able to build a 
> VM quicker.
> 
> I don’t think repo commit comments is the right place to discuss future 
> development.
> 
> 
> 
> 
> 
> 
>> On Jan 26, 2018, at 3:31 AM, Henri Beauchamp <sl...@free.fr> wrote:
>> 
>> On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote:
>> 
>> 
>>> However, it might be a problem with Dullahan, since CEF is now compiled with
>>> Ubuntu 16.04 LTS,
>> 
>> Scratch that !
>> 
>> On the CEF build Wiki, they cite 14.04, but the link points to a page that
>> itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is
>> used to build the latest CEF...
>> 
>> Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either
>> of those two could then be the Linux build system of choice).
>> 
>> 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
> 

___
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

Re: [opensource-dev] Linux

[Nicky Perian]

Having read the comments on viewer-release repo and your comment concerning ABI 
mismatch I want to submit the following:

I have put together in a VM Debian / stretch. My past linux builds have been on 
Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9.

Stretch has neither gcc-4.9 nor libpngl2. Both of these are in wheezy. Adding 
wheezy to sources.list then apt-get update and apt-get install will place these 
in stretch then, comment out the lines about wheezy in sources.list and apt-get 
update again. Don’t  apt-get upgrade with the wheezy lines active.  Building 
non Alex Ivy code went fine with this setup.

Ubuntu is a good choice also and has the advantage of being able to build a VM 
quicker.

I don’t think repo commit comments is the right place to discuss future 
development.




 

> On Jan 26, 2018, at 3:31 AM, Henri Beauchamp  wrote:
> 
> On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote:
> 
> 
>> However, it might be a problem with Dullahan, since CEF is now compiled with
>> Ubuntu 16.04 LTS,
> 
> Scratch that !
> 
> On the CEF build Wiki, they cite 14.04, but the link points to a page that
> itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is
> used to build the latest CEF...
> 
> Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either
> of those two could then be the Linux build system of choice).
> 
> 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

___
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

[opensource-dev] Linux

[Nicky Perian]

Which version of Debian does LL plan to use? Stretch is at stable.




___
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

Re: [opensource-dev] macOS build

[Nicky Perian]

Fixed.
Related to bypass of SL_Launcher. 

> On Jan 19, 2018, at 1:16 PM, Nicky Perian <nickyper...@gmail.com> wrote:
> 
> I have a bit of an issue carrying through with a kokua build. When building 
> on command line the packaged Kokua.app says it is incomplete and has a stop 
> sign overlay icon. When I open and look inside I can run both the SL_Launcher 
> and the Kokua Viewer.app with no problems.
> 
> When built using Xcode IDE it kicks
> Launch error
> 
> 
> There is a problem launching using posix_spawn (error code: 13)
> 
> 
> 
> Any idea what I am doing wrong?
> 
> Nicky

___
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

[opensource-dev] macOS build

[Nicky Perian]

I have a bit of an issue carrying through with a kokua build. When building
on command line the packaged Kokua.app says it is incomplete and has a stop
sign overlay icon. When I open and look inside I can run both the
SL_Launcher and the Kokua Viewer.app with no problems.

When built using Xcode IDE it kicks

*Launch error*


There is a problem launching using posix_spawn (error code: 13)



Any idea what I am doing wrong?

Nicky
___
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

[opensource-dev] autobuild-1.1 on a new macOS xcode8.3.3

[Nicky Perian]

Williams-iMac:viewer64 bill$ hg tip

changeset:   38165:7c191babc4f6

tag: tip

user:Nat Goodspeed 

date:Fri Dec 15 17:07:37 2017 -0500

summary: MAINT-8087: Update to viewer-manager build 511462


Williams-iMac:viewer64 bill$ autobuild --version

autobuild 1.1.7


autobuild configure --address-size=64 -v -c ReleaseOS --
-DENABLE_SIGNING:BOOL=OFF -DLL_TESTS:BOOL=OFF -DFMODEX:BOOL=OFF
-DOPENAL:BOOL=OFF -DPACKAGE:BOOL=ON  -DUSE_KDU:BOOL=OFF
-DRELEASE_CRASH_REPORTING:BOOL=OFF


  File "/usr/local/bin/autobuild", line 9, in 

load_entry_point('autobuild==1.1.7', 'console_scripts', 'autobuild')()

  File "/Library/Python/2.7/site-packages/autobuild/autobuild_main.py",
line 263, in main

sys.exit(Autobuild().main(sys.argv[1:]))

  File "/Library/Python/2.7/site-packages/autobuild/autobuild_main.py",
line 250, in main

tool_to_run.run(args)

  File 
"/Library/Python/2.7/site-packages/autobuild/autobuild_tool_configure.py",
line 105, in run

environment=environment)

  File 
"/Library/Python/2.7/site-packages/autobuild/autobuild_tool_configure.py",
line 158, in _configure_a_configuration

return configure_executable(extra_arguments, environment=environment)

  File "/Library/Python/2.7/site-packages/autobuild/executable.py", line
104, in __call__

return subprocess.call(commandlist, env=environment)

  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 522, in call

return Popen(*popenargs, **kwargs).wait()

  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 710, in __init__

errread, errwrite)

  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 1335, in _execute_child

raise child_exception

OSError: [Errno 2] No such file or directory


variables

LL_BUILD_DARWIN_BASE_SWITCHES="-fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot /Xcode/Xcode_8.3.3.app/
Contents/Developer/Platforms/MacOSX.platform/Developer/
SDKs/MacOSX10.12.sdk/"



**


Need help.

Any ideas as to what I have messed up?


*

*Found the problem*. I installed cmake per wiki instructions and it was not
in path. Reinstalled using homebrew

   to /usr/local/bin/cmake.


Decided to go ahead and post  in case someone else has the problem.
___
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

Re: [opensource-dev] Viewer Manager (Launcher) and AntiVirus

[Nicky Perian]

Sounds similar to what I reported here:
https://jira.secondlife.com/browse/BUG-134328
I haven't been able to make it fail since.



On Thu, Sep 28, 2017 at 8:47 AM, Niran 
wrote:

> Avira (and presumably all others) goes nuts on vmp_util.exe whenever it
> appears anywhere, worse, when i configure the viewer and it downloads and
> extracts the viewer manager package it immediately flags it as potentially
> dangerous in such a way that said file becomes completely phased, i cannot
> remove it, move it or otherwise interact with it and the configuration
> fails with "permission denied" until i restart the PC. I wonder what i can
> do about it, the moment i'm going to pack this thing into the Viewer
> package and offer a download people will chop my head off that its infected
> with Viruses.
>
> I know AntiVirus applications are shit but i'm worried about this
> happening not just to me but to basically every single user, this would be
> absolutely horrible.
>
> ___
> 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
>
___
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

Re: [opensource-dev] macOS -DVIEWER-CHANNEL

[Nicky Perian]

The same escape sequence on autobuild-1.0 and code from 5.0.7 works on win,
macOS, and Linux.
Also, the sequence works correctly on windows for both 5.1.0 and 5.0.7

On Fri, Aug 11, 2017 at 3:10 PM, Cinder Roxley <cin...@alchemyviewer.org>
wrote:

> GIGO
>
>
> On August 11, 2017 at 2:47:04 PM, Nicky Perian (nickyper...@gmail.com)
> wrote:
>
> When -DVIEWER_CHANNEL="\"SecondLife Test Channel Assignment\"" is passed
> on configure a malformed filename is constructed for dmg. This produces
> Second_Life_SecondLife\\_Test\\_Channel\\_Assignment_5.1.0_x86_64.dmg
>
> and the dmg is not useable.
>
>
> ___
> 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
>
___
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

[opensource-dev] macOS -DVIEWER-CHANNEL

[Nicky Perian]

When -DVIEWER_CHANNEL="\"SecondLife Test Channel Assignment\"" is passed on
configure a malformed filename is constructed for dmg. This produces
Second_Life_SecondLife\\_Test\\_Channel\\_Assignment_5.1.0_x86_64.dmg

and the dmg is not useable.
___
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

[opensource-dev] Building macOS

[Nicky Perian]

Once the local LL libs are good to go, how can I prevent them from
rebuilding every time a change is made to a newview source file?
___
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

Re: [opensource-dev] viewer64 macOS and cmake-3.5

[Nicky Perian]

Resolved with help from Nat and reference to previous fix on windows
platform suggested by Nicky D.

On Tue, Aug 8, 2017 at 5:53 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Tue, Aug 8, 2017 at 6:50 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> I resolved by
>> https://bitbucket.org/kokua/viewer-build-variables/commits/c
>> a60af3918d5e2eacfd699d878cdd63ae242232b
>>
>> added darwin RELEASEOS and RELWITHDEBINFOOS to the variables file.
>>
>
> Ah. Thank you; obviously I overlooked those config values.
>
___
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

Re: [opensource-dev] viewer64 macOS and cmake-3.5

[Nicky Perian]

..//indra


On Tue, Aug 8, 2017 at 9:27 AM, Nicky Perian <nickyper...@gmail.com> wrote:

> When executing autobuild configure the default source tree looks one
> directory level up for the source tree. I have tried to pass
> -DCMAKE_SOURCE_DIR= and ../ is always appended to
> the configure command.
>
> Is there a command I don't know about?
>
>
___
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

[opensource-dev] viewer64 macOS and cmake-3.5

[Nicky Perian]

When executing autobuild configure the default source tree looks one
directory level up for the source tree. I have tried to pass
-DCMAKE_SOURCE_DIR= and ../ is always appended to
the configure command.

Is there a command I don't know about?
___
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

[opensource-dev] build viewer64 dependencies

[Nicky Perian]

https://bitbucket.org/lindenlab/autobuild-1.1
https://bitbucket.org/lindenlab/viewer-build-variables

Are these up to date with LL's build system?
___
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

Re: [opensource-dev] Python errors after update of viewer64

[Nicky Perian]

My fault. While working the problem with the "mq" extension I overwrote
python with the 64 bit version.
Reinstalled 32 bit and it works.

On Sat, Jul 22, 2017 at 10:56 PM, Nicky Perian <nickyper...@gmail.com>
wrote:

> Note: there is no problem with autobuild 1.0.3 with default viewer code.
>
> autobuild --version errors out with --
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --version
> Traceback (most recent call last):
>   File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
> line 6, in 
> from pkg_resources import load_entry_point
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\pkg_resources\__init__.py",
> line 36, in 
> import email.parser
>   File "C:\Python27\Lib\email\parser.py", line 12, in 
> from email.feedparser import FeedParser
>   File "C:\Python27\Lib\email\feedparser.py", line 27, in 
> from email import message
>   File "C:\Python27\Lib\email\message.py", line 16, in 
> import email.charset
>   File "C:\Python27\Lib\email\charset.py", line 13, in 
> import email.base64mime
>   File "C:\Python27\Lib\email\base64mime.py", line 40, in 
> from email.utils import fix_eols
>   File "C:\Python27\Lib\email\utils.py", line 28, in 
> import socket
>   File "C:\Python27\Lib\socket.py", line 47, in 
> import _socket
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> Then when trying to update autobuild --
> This happens for
> pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>pip install hg+
> http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild
> Traceback (most recent call last):
>   File "C:\Python27\Lib\runpy.py", line 162, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
>   File "C:\Python27\Lib\runpy.py", line 72, in _run_code
> exec code in run_globals
>   File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\pip.exe\__main__.py",
> line 5, in 
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\__init__.py",
> line 21, in 
> from pip._vendor.requests.packages.urllib3.exceptions import
> DependencyWarning
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\_vendor\requests\__init__.py",
> line 62, in 
> from .packages.urllib3.exceptions import DependencyWarning
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\_
> vendor\requests\packages\__init__.py", line 29, in 
> import urllib3
> ImportError: No module named urllib3
>
___
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

[opensource-dev] Python errors after update of viewer64

[Nicky Perian]

Note: there is no problem with autobuild 1.0.3 with default viewer code.

autobuild --version errors out with --
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --version
Traceback (most recent call last):
  File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
6, in 
from pkg_resources import load_entry_point
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\pkg_resources\__init__.py",
line 36, in 
import email.parser
  File "C:\Python27\Lib\email\parser.py", line 12, in 
from email.feedparser import FeedParser
  File "C:\Python27\Lib\email\feedparser.py", line 27, in 
from email import message
  File "C:\Python27\Lib\email\message.py", line 16, in 
import email.charset
  File "C:\Python27\Lib\email\charset.py", line 13, in 
import email.base64mime
  File "C:\Python27\Lib\email\base64mime.py", line 40, in 
from email.utils import fix_eols
  File "C:\Python27\Lib\email\utils.py", line 28, in 
import socket
  File "C:\Python27\Lib\socket.py", line 47, in 
import _socket
ImportError: DLL load failed: %1 is not a valid Win32 application.

Then when trying to update autobuild --
This happens for
pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>pip install hg+
http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild
Traceback (most recent call last):
  File "C:\Python27\Lib\runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "C:\Python27\Lib\runpy.py", line 72, in _run_code
exec code in run_globals
  File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\pip.exe\__main__.py", line
5, in 
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\__init__.py", line
21, in 
from pip._vendor.requests.packages.urllib3.exceptions import
DependencyWarning
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\_vendor\requests\__init__.py",
line 62, in 
from .packages.urllib3.exceptions import DependencyWarning
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\pip\_vendor\requests\packages\__init__.py",
line 29, in 
import urllib3
ImportError: No module named urllib3
___
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

[opensource-dev] Update to mercurial and conflict with "hg policy" local extension.

[Nicky Perian]

I recently updated mercurial 4.2.2 and encountered a crash at any hg
invocation.

hg policy caused the crash when the system extension "mq" was also used.

Does hg policy need a rewrite?
___
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

Re: [opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

The default was always Nvidia card and each program can be set to Nivida or
Integrated graphics. Once the updated installer was in place it pulled
installed and executed it. However, the time from starting the viewer til
Login page presents is about 25 seconds even with no updates pending.

The web components on the login page are missing. (jira pending)


On Fri, Jun 30, 2017 at 12:11 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jun 30, 2017 at 12:10 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> I just forced in Nvidia settings for SL_Launcher.exe to use the Nvidia
>> driver and the problem was still present.
>>
>
> But SL_Launcher.exe doesn't try to use 3D graphics. It manages updates,
> then launches the actual viewer. You would still need to tell Nvidia the
> executable name for the actual viewer.
>
___
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

Re: [opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

Keep forgetting reply all. To complete the record;
I tried to forcing Integrated Graphics (Intel) and Enhanced Graphics
(Nvidia) and there is no difference.

On Fri, Jun 30, 2017 at 11:02 AM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jun 30, 2017 at 11:52 AM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> On my alienware it is a Nvidia setting to use its driver as default and
>> can also be set for a specific *.exe program name.
>>
>> On Fri, Jun 30, 2017 at 10:26 AM, Jonathan Welch <jhwe...@gmail.com>
>> wrote:
>>
>>> Some systems have two built in graphics chips such as Lenovo laptops
>>> with a system called Optimus. One graphics chip is very weak and the other
>>> much stronger, bit also more power hungry. As I recall it took a while to
>>> register the .EXE name with Nvidia so the stronger chip runs the viewer.
>>>
>>> Is this registration underway already?
>>>
>>
> I don't know about that registration, but will ask.
>
> What I think you're saying, though, is that detection of the issue may be
> complicated. In fact it might be impossible for SL_Launcher.exe to detect
> which potential graphics driver is configured to handle our viewer. Is that
> a fair statement?
>
___
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

Re: [opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

On my alienware it is a Nvidia setting to use its driver as default and can
also be set for a specific *.exe program name.

On Fri, Jun 30, 2017 at 10:26 AM, Jonathan Welch <jhwe...@gmail.com> wrote:

> Some systems have two built in graphics chips such as Lenovo laptops with
> a system called Optimus. One graphics chip is very weak and the other much
> stronger, bit also more power hungry. As I recall it took a while to
> register the .EXE name with Nvidia so the stronger chip runs the viewer.
>
> Is this registration underway already?
>
> On Jun 30, 2017 9:23 AM, "Nat Goodspeed" <n...@lindenlab.com> wrote:
>
>> On Fri, Jun 30, 2017 at 6:36 AM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> I may be jumping ahead, but with an opensource build and built installer
>>> used :
>>>
>>> With shortcut to "C:\Program Files\SecondLifeProjectAlexIvy\SL_Launcher.exe"
>>> --set InstallLanguage en
>>> Program does not run log follows:
>>>
>>> 2017-06-30T09:56:59Z INFO: update_manager.py(261) : getBitness: Setting
>>> bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
>>>
>>
>> This is the key log line here. We have reports that certain graphics
>> cards do not play well at all with our Alex Ivy 64-bit viewer.
>>
>> The new Viewer Management Process component of Alex Ivy (SL_Launcher) is
>> a small program that runs first to manage updates and so forth. This is the
>> VMP trying to optimize your user experience by downloading and installing
>> the corresponding 32-bit viewer.
>>
>>
>>> 2017-06-30T09:57:00Z INFO: update_manager.py(354) : query_vvm:
>>> Requesting update for channel 'Second Life Project Alex Ivy' version
>>> 5.1.0.171810121 platform win32 platform version 10.0.15063 allow_test
>>> testok id 8ff7c019124918cd78f655542a14c58e
>>> 2017-06-30T09:57:01Z INFO: update_manager.py(361) : query_vvm: received
>>> result from VVM: {'platforms': {}, 'required': True, 'version':
>>> '5.1.0.171810121', 'channel': 'Second Life Project Alex Ivy', 'more_info':
>>> None}
>>>
>>
>> And here's the thing: you're running a self-built viewer. Our Viewer
>> Version Manager knows nothing about it and cannot provide the corresponding
>> 32-bit viewer for you.
>>
>>
>>> 2017-06-30T09:57:01Z WARNING: update_manager.py(398) : query_vvm:
>>> Unexpected response - no data for platform 'win32': {'platforms': {},
>>> 'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
>>> Project Alex Ivy', 'more_info': None}
>>> 2017-06-30T09:57:01Z ERROR: update_manager.py(401) : query_vvm: Error
>>> from reading VVM response: KeyError('win32',)
>>> 2017-06-30T09:57:01Z ERROR: update_manager.py(411) : query_vvm: Could
>>> not obtain 32 bit viewer information.  Response from VVM was {'platforms':
>>> {}, 'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
>>> Project Alex Ivy', 'more_info': None}
>>>
>>
>>
>> With shortcut pointing to "C:\Program Files\SecondLifeProjectAlexIvy
>>> \SecondLifeProjectAlexIvy.exe"
>>> Runs OK.
>>>
>>
>> That's useful information: we should probably refine our graphics
>> card/driver test to allow running 64-bit Alex Ivy on your configuration.
>> Please file a Jira with pertinent graphics card/driver information and the
>> statement that 64-bit Alex Ivy runs well for you?
>>
>> But in general, please don't hack the shortcut. We've moved all the
>> update machinery from the viewer executable to the separate SL_Launcher
>> program. If you directly run SecondLifeProjectAlexIvy.exe, you will not get
>> updates.
>>
>> There are several useful things about having a whole separate program to
>> manage updates. The most basic of them is this: SL_Launcher is a 32-bit
>> program, even in 64-bit viewer installs. Even if a user running 32-bit
>> Windows downloads a 64-bit installer, s/he can still run SL_Launcher, which
>> will determine that the 64-bit viewer can't possibly run and will download
>> and run the corresponding 32-bit installer.
>>
>> Because there are graphics cards/drivers that apparently don't play well
>> with 64-bit Alex Ivy, we use that same logic to ensure that users with
>> those cards/drivers use the 32-bit viewer instead. I'm glad to hear the
>> test is overly pessimistic in some cases.
>>
>> All this machinery is still brand-new. We naturally must ensure that
>> developers can run self-built viewers without undue difficulty. You can
>> understand, though, that our initial focus has been on end-users.
>>
>> ___
>> 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
>>
>
___
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

Re: [opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

*That's useful information: we should probably refine our graphics
card/driver test to allow running 64-bit Alex Ivy on your configuration.
Please file a Jira with pertinent graphics card/driver information and the
statement that 64-bit Alex Ivy runs well for you?*

Need a new project viewer update in order to test. Will post to jira once a
new SL installer is up.



On Fri, Jun 30, 2017 at 8:23 AM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jun 30, 2017 at 6:36 AM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> I may be jumping ahead, but with an opensource build and built installer
>> used :
>>
>> With shortcut to "C:\Program Files\SecondLifeProjectAlexIvy\SL_Launcher.exe"
>> --set InstallLanguage en
>> Program does not run log follows:
>>
>> 2017-06-30T09:56:59Z INFO: update_manager.py(261) : getBitness: Setting
>> bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
>>
>
> This is the key log line here. We have reports that certain graphics cards
> do not play well at all with our Alex Ivy 64-bit viewer.
>
> The new Viewer Management Process component of Alex Ivy (SL_Launcher) is a
> small program that runs first to manage updates and so forth. This is the
> VMP trying to optimize your user experience by downloading and installing
> the corresponding 32-bit viewer.
>
>
>> 2017-06-30T09:57:00Z INFO: update_manager.py(354) : query_vvm: Requesting
>> update for channel 'Second Life Project Alex Ivy' version 5.1.0.171810121 
>> platform
>> win32 platform version 10.0.15063 allow_test testok id
>> 8ff7c019124918cd78f655542a14c58e
>> 2017-06-30T09:57:01Z INFO: update_manager.py(361) : query_vvm: received
>> result from VVM: {'platforms': {}, 'required': True, 'version':
>> '5.1.0.171810121', 'channel': 'Second Life Project Alex Ivy', 'more_info':
>> None}
>>
>
> And here's the thing: you're running a self-built viewer. Our Viewer
> Version Manager knows nothing about it and cannot provide the corresponding
> 32-bit viewer for you.
>
>
>> 2017-06-30T09:57:01Z WARNING: update_manager.py(398) : query_vvm:
>> Unexpected response - no data for platform 'win32': {'platforms': {},
>> 'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
>> Project Alex Ivy', 'more_info': None}
>> 2017-06-30T09:57:01Z ERROR: update_manager.py(401) : query_vvm: Error
>> from reading VVM response: KeyError('win32',)
>> 2017-06-30T09:57:01Z ERROR: update_manager.py(411) : query_vvm: Could not
>> obtain 32 bit viewer information.  Response from VVM was {'platforms': {},
>> 'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
>> Project Alex Ivy', 'more_info': None}
>>
>
>
> With shortcut pointing to "C:\Program Files\SecondLifeProjectAlexIvy
>> \SecondLifeProjectAlexIvy.exe"
>> Runs OK.
>>
>
> That's useful information: we should probably refine our graphics
> card/driver test to allow running 64-bit Alex Ivy on your configuration.
> Please file a Jira with pertinent graphics card/driver information and the
> statement that 64-bit Alex Ivy runs well for you?
>
> But in general, please don't hack the shortcut. We've moved all the update
> machinery from the viewer executable to the separate SL_Launcher program.
> If you directly run SecondLifeProjectAlexIvy.exe, you will not get updates.
>
> There are several useful things about having a whole separate program to
> manage updates. The most basic of them is this: SL_Launcher is a 32-bit
> program, even in 64-bit viewer installs. Even if a user running 32-bit
> Windows downloads a 64-bit installer, s/he can still run SL_Launcher, which
> will determine that the 64-bit viewer can't possibly run and will download
> and run the corresponding 32-bit installer.
>
> Because there are graphics cards/drivers that apparently don't play well
> with 64-bit Alex Ivy, we use that same logic to ensure that users with
> those cards/drivers use the 32-bit viewer instead. I'm glad to hear the
> test is overly pessimistic in some cases.
>
> All this machinery is still brand-new. We naturally must ensure that
> developers can run self-built viewers without undue difficulty. You can
> understand, though, that our initial focus has been on end-users.
>
___
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

Re: [opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

What is this a feature or hack?

On Fri, Jun 30, 2017 at 5:36 AM, Goddess: Primal Chaos <
supp...@koramgame.mail.helpshift.com> wrote:

> Dear player, Thank you very much for contacting us by mail. As the
> language or region of your email can’t be automatically identified, we have
> to manually sort through each and every issue then send these on to the
> relevant GM. - If you are able to log in to the game, we recommend you send
> a message to us in-game via Settings-Account-Help. - If you can’t find your
> account, usually it means you’re using the wrong login method or server.
> Please confirm you’re using the same login method as before and have
> selected the correct server. Please note that even if have bound to your
> Facebook or Google account, if you are using "Sign In" to login, please
> login exactly as previously since data is not exchanged between the three
> different login methods. Please leave your correct server and character
> name (if you’re using any special symbols in your name, please ensure
> you’re continuing to do so) and we’ll check your login method as soon as
> possible for you to. Thanks for your support and cooperation!
> ### Do not reply below this line ###
> Goddess: Primal Chaos
> June 30, 2017, 05:36 -0500
> Dear player,
> Thank you very much for contacting us by mail. As the language or region
> of your email can’t be automatically identified, we have to manually sort
> through each and every issue then send these on to the relevant GM.
> - If you are able to log in to the game, we recommend you send a message
> to us in-game via Settings-Account-Help.
> - If you can’t find your account, usually it means you’re using the wrong
> login method or server. Please confirm you’re using the same login method
> as before and have selected the correct server.
> Please note that even if have bound to your Facebook or Google account, if
> you are using "Sign In" to login, please login exactly as previously since
> data is not exchanged between the three different login methods.
> Please leave your correct server and character name (if you’re using any
> special symbols in your name, please ensure you’re continuing to do so) and
> we’ll check your login method as soon as possible for you to.
> Thanks for your support and cooperation!
> --
> Goddess: Primal Chaos
> June 30, 2017, 05:36 -0500
> Hi, thanks for contacting Customer Service. This is an automated reply,
> hope to help you solve common problems. Please tell me your server and
> character's name. Manual service will contact you as soon as possible!
> Thank you very much for the support and patience.
>
> If you have a problem with recharge, please leave us the necessary
> information.
> 1. the name of the character(IGN)
> 2. the server
> 3. the number of your order
> # via Google, we need the GPA.---X
> #via Apple, we need the number from the receipt and also a screenshot that
> you take from the Itunes of your computer.
> #other ways, please let us know the exact way of recharging and the number
> of it
> 4. the UID of this character (which you can see in the game, but if you
> cannot find it that will be fine )
> We are really hope that we could help!
>
> If you want to report a BUG, please try to tell us more details, such as
> related character names and servers. The most important is the exact time
> (better with hour and minute), so that we locate and check the problem more
> quickly. Thank you in advance.
> --
> Nicky Perian
> June 30, 2017, 05:36 -0500
> *[opensource-dev] viewer64 SL_Launcher*
>
>
> I may be jumping ahead, but with an opensource build and built installer
> used :
>
> With shortcut to "C:\Program
> Files\SecondLifeProjectAlexIvy\SL_Launcher.exe" --set InstallLanguage en
> Program does not run log follows:
>
> 2017-06-30T09:56:56Z INFO: vmp_util.py(58) : getLogger: 
> Running SL_Launcher
> 2017-06-30T09:56:56Z INFO: SL_Launcher(188) : main: Viewer version
> 5.1.0.171810121
> 2017-06-30T09:56:56Z INFO: vmp_util.py(86) : stream:  running
> subcommand ['wmic', 'path', 'Win32_VideoController', 'get', 'NAME']; any
> stderr follows
> 2017-06-30T09:56:59Z INFO: update_manager.py(261) : getBitness: Setting
> bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
> 2017-06-30T09:56:59Z INFO: vmp_util.py(86) : stream:  running
> subcommand ['wmic', 'csproduct', 'get', 'UUID']; any stderr follows
> 2017-06-30T09:57:00Z INFO: update_manager.py(354) : query_vvm: Requesting
> update for channel 'Second Life Project Alex Ivy' version 5.1.0.171810121
> platform win32 platform version 10.0.15063 allow_test testok

[opensource-dev] viewer64 SL_Launcher

[Nicky Perian]

I may be jumping ahead, but with an opensource build and built installer
used :

With shortcut to "C:\Program
Files\SecondLifeProjectAlexIvy\SL_Launcher.exe" --set InstallLanguage en
Program does not run log follows:

2017-06-30T09:56:56Z INFO: vmp_util.py(58) : getLogger: 
Running SL_Launcher
2017-06-30T09:56:56Z INFO: SL_Launcher(188) : main: Viewer version
5.1.0.171810121
2017-06-30T09:56:56Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'path', 'Win32_VideoController', 'get', 'NAME']; any
stderr follows
2017-06-30T09:56:59Z INFO: update_manager.py(261) : getBitness: Setting
bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
2017-06-30T09:56:59Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'csproduct', 'get', 'UUID']; any stderr follows
2017-06-30T09:57:00Z INFO: update_manager.py(354) : query_vvm: Requesting
update for channel 'Second Life Project Alex Ivy' version 5.1.0.171810121
platform win32 platform version 10.0.15063 allow_test testok id
8ff7c019124918cd78f655542a14c58e
2017-06-30T09:57:01Z INFO: update_manager.py(361) : query_vvm: received
result from VVM: {'platforms': {}, 'required': True, 'version':
'5.1.0.171810121', 'channel': 'Second Life Project Alex Ivy', 'more_info':
None}
2017-06-30T09:57:01Z WARNING: update_manager.py(398) : query_vvm:
Unexpected response - no data for platform 'win32': {'platforms': {},
'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
Project Alex Ivy', 'more_info': None}
2017-06-30T09:57:01Z ERROR: update_manager.py(401) : query_vvm: Error from
reading VVM response: KeyError('win32',)
2017-06-30T09:57:01Z ERROR: update_manager.py(411) : query_vvm: Could not
obtain 32 bit viewer information.  Response from VVM was {'platforms': {},
'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
Project Alex Ivy', 'more_info': None}
2017-06-30T09:58:24Z INFO: vmp_util.py(58) : getLogger: 
Running SL_Launcher
2017-06-30T09:58:24Z INFO: SL_Launcher(188) : main: Viewer version
5.1.0.171810121
2017-06-30T09:58:24Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'path', 'Win32_VideoController', 'get', 'NAME']; any
stderr follows
2017-06-30T09:58:24Z INFO: update_manager.py(261) : getBitness: Setting
bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
2017-06-30T09:58:24Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'csproduct', 'get', 'UUID']; any stderr follows
2017-06-30T09:58:24Z INFO: update_manager.py(354) : query_vvm: Requesting
update for channel 'Second Life Project Alex Ivy' version 5.1.0.171810121
platform win32 platform version 10.0.15063 allow_test testok id
8ff7c019124918cd78f655542a14c58e
2017-06-30T09:58:24Z INFO: update_manager.py(361) : query_vvm: received
result from VVM: {'platforms': {}, 'required': True, 'version':
'5.1.0.171810121', 'channel': 'Second Life Project Alex Ivy', 'more_info':
None}
2017-06-30T09:58:24Z WARNING: update_manager.py(398) : query_vvm:
Unexpected response - no data for platform 'win32': {'platforms': {},
'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
Project Alex Ivy', 'more_info': None}
2017-06-30T09:58:24Z ERROR: update_manager.py(401) : query_vvm: Error from
reading VVM response: KeyError('win32',)
2017-06-30T09:58:24Z ERROR: update_manager.py(411) : query_vvm: Could not
obtain 32 bit viewer information.  Response from VVM was {'platforms': {},
'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
Project Alex Ivy', 'more_info': None}
2017-06-30T10:00:06Z INFO: vmp_util.py(58) : getLogger: 
Running SL_Launcher
2017-06-30T10:00:06Z INFO: SL_Launcher(188) : main: Viewer version
5.1.0.171810121
2017-06-30T10:00:06Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'path', 'Win32_VideoController', 'get', 'NAME']; any
stderr follows
2017-06-30T10:00:07Z INFO: update_manager.py(261) : getBitness: Setting
bitness to 32 due to HD Graphics Win 64 Bit incompatibility.
2017-06-30T10:00:07Z INFO: vmp_util.py(86) : stream:  running
subcommand ['wmic', 'csproduct', 'get', 'UUID']; any stderr follows
2017-06-30T10:00:07Z INFO: update_manager.py(354) : query_vvm: Requesting
update for channel 'Second Life Project Alex Ivy' version 5.1.0.171810121
platform win32 platform version 10.0.15063 allow_test testok id
8ff7c019124918cd78f655542a14c58e
2017-06-30T10:00:07Z INFO: update_manager.py(361) : query_vvm: received
result from VVM: {'platforms': {}, 'required': True, 'version':
'5.1.0.171810121', 'channel': 'Second Life Project Alex Ivy', 'more_info':
None}
2017-06-30T10:00:07Z WARNING: update_manager.py(398) : query_vvm:
Unexpected response - no data for platform 'win32': {'platforms': {},
'required': True, 'version': '5.1.0.171810121', 'channel': 'Second Life
Project Alex Ivy', 'more_info': None}
2017-06-30T10:00:07Z ERROR: update_manager.py(401) : query_vvm: Error from
reading VVM 

[opensource-dev] Viewer Channel

[Nicky Perian]

Has the escape sequence for viewer channel changed?
-DVIEWER_CHANNEL="\"Second Life Project Alex Ivy\""

This picks Test Icon set.
The blue top menu bar is present.

I would not be using this channel. It is used to prove the point.
___
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

[opensource-dev] Windows installer slower

[Nicky Perian]

Has anyone noticed it is taking longer to install the viewer since the
Windows Creator update?

Extract of xml files is taking longer on my machine.
___
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

Re: [opensource-dev] How to deal with FMODEX?

[Nicky Perian]

Which platform are you using?

You may want to use a non-commercial license of FmodEx. Then, send an email
to FMOD support explaining your use of non-commercial provisions of their
license and that you need access of FmodEx archives.

It may take time for them to respond as there isn't any money involved.

However, I the folks at FMOD are friendly and usually accommodating.


Nicky

On Sat, Feb 25, 2017 at 5:38 AM, Peter Gloor  wrote:

> Following current instructions I've been trying to build an 'open' 32-bit
> viewer. After I failed building viewer-release with a bunch of errors I
> tried to build kokua-os, kokua-sl and phoenix-firestorm-lgpl. Except with
> Linden Labs viewer-release I succeeded when I configured autobuild for no
> FMODEX.
>
> I understand that for licencing reasons the FmodEx package cannot be
> distributed by Linden Lab and I have to manually do what Linden Lab does in
> the 3p-fmodex package to create my own package for FmodEx.
>
> The problem I have is that FmodEx is no longer actively supported and does
> no longer appear anywhere on the download pages at http://www.fmod.org.
>
> Any idea how to best deal with this problem? Is there another FMOD product
> I can pick the missing parts from? Or is there an alternative I'm not aware
> of? Any hints are welcome.
>
> Thanks in advance.
>
> Peter
>
> P.S. I'll take a look into and sort out the other problems I encountered
> with viewer-release after I've solved the FmodEx part. I successfully
> custom built Linden Lab viewers and Firestorm in the past (> 2 years ago).
>
> ___
> 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
>
___
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

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

[Nicky Perian]

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


On Sat, Feb 18, 2017 at 3:11 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Feb 18, 2017 1:33 PM, "Nicky Perian" <nickyper...@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.
>
___
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

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

[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)

On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian <nickyper...@gmail.com> wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (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 
> 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:25 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
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

Re: [opensource-dev] Linux

[Nicky Perian]

>The "one, true Linux?"
No not at all. Just something better.
A few years ago Oz published a detailed recipe for your build system that
was an original work by Donald Kjer. I can't find the reference atm but i
would bet there isn't anyone besides
Don that would be able to redo it from a blank box.



On Sun, Jan 29, 2017 at 7:54 PM, Monty Brandenberg <mo...@lindenlab.com>
wrote:

> On 1/29/2017 8:39 PM, Nicky Perian wrote:
>
> > Will LL use a build system that can be updated as opposed to the current
> > out of date system? Hopefully, the build system will be a standard off
> > the shelf that everyone can install and without any mix and match
> specials.
>
> The "one, true Linux?"
>
> /me reaches for box of popcorn...
>
> ___
> 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
>
___
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

[opensource-dev] Linux

[Nicky Perian]

Questions:

Will LL use a build system that can be updated as opposed to the current
out of date system? Hopefully, the build system will be a standard off the
shelf that everyone can install and without any mix and match specials.

Will there be LL developed QA procedures for the linux builds?

Granted, *.deb is a much used package manager for debian and derived
distros. Will any other distro package managers be developed? I assume the
answer is no so, will OS developer submissions of other package manager
formats be accepted?

Nicky
___
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

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

[Nicky Perian]

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?

On Fri, Jan 20, 2017 at 9:55 AM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> Moving on to Linux and Linux64.
>>
>
> Now you're breaking trail. For the present, we're focusing on Windows and
> Mac.
>
>
>> 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.
>
___
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

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

[Nicky Perian]

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?



On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian <nickyper...@gmail.com> wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (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 
> 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:25 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
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

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

[Nicky Perian]

@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




On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian <nickyper...@gmail.com> wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (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 
> 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:25 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
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

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

[Nicky Perian]

and more...
>>You might have to specify "autobuild uninstall --address-size 64 x"
(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 
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:25 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> Does "autobuild uninstall x" work for autobuild-1.1?
>>
>
> You might have to specify "autobuild uninstall --address-size 64 x"
> (or -A 64) for the autobuild uninstall command to select the correct build
> directory.
>
___
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

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

[Nicky Perian]

>>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 
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) <
o...@lindenlab.com> wrote:

> On 2017-01-13 17:01 , Nicky Perian wrote:
>
> Does "autobuild uninstall x" 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: o...@lindenlab.com | Real Life: Scott Lawrence
> LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>
>
> ___
> 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
>
___
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

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

[Nicky Perian]

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

On Thu, Jan 12, 2017 at 12:59 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> KDU build here was indistinguishable from the 32bit viewer-release on
> first inspection.
>
> Tried both with full cache and cleaned one.
>
> On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
>> [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.
>>
>> On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. <sl.nicky...@googlemail.com>
>> wrote:
>>
>>> 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
>>>
>>>
>>
>> ___
>> 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
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>
>
___
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

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

[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.

On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. 
wrote:

> 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
>
>
___
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

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

[Nicky Perian]

brute force setting of LL_BUILD environment variable.
There may be a better/smarter way, but it appears to work.
# HG changeset patch
# User Nicky Perian <nickyper...@yahoo.com>
# 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)



On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> 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\viewe

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

[Nicky Perian]

LL list server problem so resending.

On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> 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.
>
>
>
>
> On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
>> /DLL_RLEASE_FOR_DOWNLOAD=1
>> >> /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
>>
>
>
___
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

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

[Nicky Perian]

LL list server issue so resending

On Sat, Jan 7, 2017 at 10:13 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> brute force setting of LL_BUILD environment variable.
> There may be a better/smarter way, but it appears to work.
> # HG changeset patch
> # User Nicky Perian <nickyper...@yahoo.com>
> # 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)
>
>
>
> On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
>> 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]

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

[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.




On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
> /DLL_RLEASE_FOR_DOWNLOAD=1
> >> /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
>
___
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

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

[Nicky Perian]

(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.



On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> >>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.
>
> You can achieve that either by something like:
>
> eval "$(autobuild source_environment)"
>
> or something more like:
>
> varsfile="$(mktemp -t vars.)"
> 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.
>
___
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

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

[Nicky Perian]

>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



On Fri, Jan 6, 2017 at 4:16 AM, Argent <secret.arg...@gmail.com> wrote:

> 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.
>
> On Jan 5, 2017 19:52, "Nicky Perian" <nickyper...@gmail.com> wrote:
>
> 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.
>
>
>
>
> On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> >>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.
>>
>> You can achieve that either by something like:
>>
>> eval "$(autobuild source_environment)"
>>
>> or something more like:
>>
>> varsfile="$(mktemp -t vars.)"
>> 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.
>>
>
>
> ___
> 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
>
>
>
___
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

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

[Nicky Perian]

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.




On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> >>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.
>
> You can achieve that either by something like:
>
> eval "$(autobuild source_environment)"
>
> or something more like:
>
> varsfile="$(mktemp -t vars.)"
> 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.
>
___
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

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

[Nicky Perian]

tem32\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>

On Thu, Jan 5, 2017 at 1:16 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Wed, Jan 4, 2017 at 7:43 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> >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.
>>
>
> 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=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.
>
___
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

Re: [opensource-dev] windows build issues

[Nicky Perian]

Nope.
Only 32.

>From README_BUILD_FIRESTORM_WIN64.txt

1.1 Visual Studio 2013 Community Edition or better with installed 64 bit
compiler.
1.2 Or Visual Studio Express and 'Microsoft Windows SDK for Windows 7 and
.NET Framework 4'. Make sure to install at least the header and compiler
with all the latest service packs.
2. autobuild from *https://bitbucket.org/NickyD/autobuild-1.0
<https://bitbucket.org/NickyD/autobuild-1.0>*
3. FMOD, if you want sound, please see
https://bitbucket.org/NickyD/3p-fmodex



On Thu, Jan 5, 2017 at 1:45 AM, Lance Corrimal <lance.corri...@eregion.de>
wrote:

> Does that autobuild in https://bitbucket.org/lindenlab/autobuild-1.0
> support -m64?
>
> Am 04.01.2017 um 16:06 schrieb Nicky Perian:
>
> I have never used ssh://h...@bitbucket.org/NickyP/fs-autobuild-1.0. It was
> put there for reference only.
> This is what you should be using https://bitbucket.org/
> lindenlab/autobuild-1.0
>
> https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d8
> 2811f20a3c/README?at=default=file-view-default#README-263
>
> That is my dev setup and I was able to build a local FS with that setup.
> But, I had already edited up to autobuild-1.1. That is only used in one
> place at this line.
> https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d8
> 2811f20a3c/README?at=default=file-view-default#README-410
>
> Change autobuild-1.1 to autobuild-1.0 and the instruction should work.
>
> As is most often the case build instructions are a work in progress.
>
>
> On Wed, Jan 4, 2017 at 7:15 AM, Lance Corrimal <lance.corri...@eregion.de>
> wrote:
>
>> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version
>> autobuild 1.0
>>
>>
>> d:\Users\lemmy\Build\autobuild-1.0>which autobuild
>> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild
>>
>> d:\Users\lemmy\Build\autobuild-1.0>hg sum
>> Vorgõnger: 728:7c36cb02fc10 tip
>>  Search two directories up for package_override, we need this during the
>> VS build steps.
>> Zweig: default
>> ▄bernehme: (clean)
>> Aktualisiere: (aktuell)
>>
>> d:\Users\lemmy\Build\autobuild-1.0>hg in
>> Vergleiche mit ssh://h...@bitbucket.org/NickyP/fs-autobuild-1.0
>> Suche nach ─nderungen
>> Keine ─nderungen gefunden
>>
>>
>> Am 04.01.2017 um 13:46 schrieb Lance Corrimal:
>> > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian:
>> >> autobuild --version
>> >>
>> >> s/b 1.0 unless your on the viewer64 repo.
>> >>
>> > 64bit here.. using your autobuild, which used to work just fine before I
>> > reinstalled my PC...
>> >
>> > ___
>> > 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
>>
>>
>
>
___
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

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

[Nicky Perian]

Backed out changeset: 54c80e27a54f restore build switches


Building now.


Did notice other avatars are grey. Mine looks fine.


On Wed, Jan 4, 2017 at 6:43 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> >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
>
> On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> > AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-vari
>> ables\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.
>>
>> > 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

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

[Nicky Perian]

>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

On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> > 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.
>
> > 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

Re: [opensource-dev] windows build issues

[Nicky Perian]

PLATFORM: 'win32' is this normal for a 64bit build?

I suggest you take a step back and make sure you can do a viewer-release
build.

Then build firestorm 32 bit and lastly 64 bit.


On Wed, Jan 4, 2017 at 3:20 PM, Lance Corrimal <lance.corri...@eregion.de>
wrote:

> and again: autobuild itself seems to work, at least it starts to work. it
> dies at the point where it tries to download the prebuild packages.
> here is the complete output of my problem:
>
> http://susepaste.org/33664691
>
>
>
>
>
> Am 04.01.2017 um 19:58 schrieb Nicky Perian:
>
> cd into local repo  firestorm, viewer-release are any other.
> From there enter autobuild --version  an absolute path should not be
> needed to reach autobuild.
> It should give the version, If not, your path is not set or you may need
> to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment variable.
>
>
>
>
> On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal <lance.corri...@eregion.de
> > wrote:
>
>> that's what i'm using. Like I said already, I had to reinstall my
>> computer, before that I had been building viewers all the time, 32bit and
>> 64bit, no problems whatsoever.
>>
>> Now, it doesn't work with some error that looks like autobuild isn't
>> downloading the prebuilts.
>>
>>
>> Any ideas?
>>
>>
>>
>> Am 04.01.2017 um 19:15 schrieb Whirly Fizzle:
>>
>> If you are building Firestorm 64bit, you must use Nicky Dasmijn's
>> autobuild: https://bitbucket.org/NickyD/autobuild-1.0
>> NickyD / autobuild-1.0 <https://bitbucket.org/NickyD/autobuild-1.0>
>> bitbucket.org
>> Hg repository hosted by Bitbucket.
>>
>>
>>
>> --
>> *From:* opensource-dev-boun...@lists.secondlife.com
>> <opensource-dev-boun...@lists.secondlife.com>
>> <opensource-dev-boun...@lists.secondlife.com> on behalf of Lance
>> Corrimal <lance.corri...@eregion.de> <lance.corri...@eregion.de>
>> *Sent:* 04 January 2017 14:12
>> *To:* Oz Linden (Scott Lawrence); opensource-dev@lists.secondlife.com
>> *Subject:* Re: [opensource-dev] windows build issues
>>
>>
>> actually I'm building the firestorm developer version, and that used to
>> work just fine until I reinstalled my PC yesterday ;_;
>>
>> Am 04.01.2017 um 15:01 schrieb Oz Linden (Scott Lawrence):
>>
>> On 2017-01-04 08:15 , Lance Corrimal wrote:
>>
>> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version
>> autobuild 1.0
>>
>>
>> d:\Users\lemmy\Build\autobuild-1.0>which autobuild
>> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild
>> 64bit here.. using your autobuild, which used to work just fine before I
>> reinstalled my PC...
>>
>> If you're trying to build viewer64 you should be aware that it's still a
>> Work In Progress and has some limitations... Also, building that repository
>> requires using autobuild-1.1 (https://bitbucket.org/lindenl
>> ab/autobuild-1.1). All this will be updated on the wiki once this
>> project has reached the Release Candidate stage.
>> lindenlab / autobuild-1.1 <https://bitbucket.org/lindenlab/autobuild-1.1>
>> bitbucket.org
>> Hg repository hosted by Bitbucket.
>>
>> --
>> OZ LINDEN | Engineering Director, Second Life email or hangouts:
>> o...@lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual
>> Experiences <https://www.lindenlab.com>
>>
>> ___
>> 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
>>
>> ___ Policies and
>> (un)subscribe information available here: http://wiki.secondlife.com/wik
>> i/OpenSource-Dev Please read the policies before posting to keep
>> unmoderated posting privileges
>
>
> ___
> 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
>
___
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

Re: [opensource-dev] windows build issues

[Nicky Perian]

cd into local repo  firestorm, viewer-release are any other.
>From there enter autobuild --version  an absolute path should not be needed
to reach autobuild.
It should give the version, If not, your path is not set or you may need to
set AUTOBUILD='pathtoautobuild/bin/autobuild' environment variable.




On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal 
wrote:

> that's what i'm using. Like I said already, I had to reinstall my
> computer, before that I had been building viewers all the time, 32bit and
> 64bit, no problems whatsoever.
>
> Now, it doesn't work with some error that looks like autobuild isn't
> downloading the prebuilts.
>
>
> Any ideas?
>
>
>
> Am 04.01.2017 um 19:15 schrieb Whirly Fizzle:
>
> If you are building Firestorm 64bit, you must use Nicky Dasmijn's
> autobuild: https://bitbucket.org/NickyD/autobuild-1.0
> NickyD / autobuild-1.0 
> bitbucket.org
> Hg repository hosted by Bitbucket.
>
>
>
> --
> *From:* opensource-dev-boun...@lists.secondlife.com
> 
>  on behalf of Lance Corrimal
>  
> *Sent:* 04 January 2017 14:12
> *To:* Oz Linden (Scott Lawrence); opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] windows build issues
>
>
> actually I'm building the firestorm developer version, and that used to
> work just fine until I reinstalled my PC yesterday ;_;
>
> Am 04.01.2017 um 15:01 schrieb Oz Linden (Scott Lawrence):
>
> On 2017-01-04 08:15 , Lance Corrimal wrote:
>
> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version
> autobuild 1.0
>
>
> d:\Users\lemmy\Build\autobuild-1.0>which autobuild
> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild
> 64bit here.. using your autobuild, which used to work just fine before I
> reinstalled my PC...
>
> If you're trying to build viewer64 you should be aware that it's still a
> Work In Progress and has some limitations...
>
> Also, building that repository requires using autobuild-1.1 (
> https://bitbucket.org/lindenlab/autobuild-1.1). All this will be updated
> on the wiki once this project has reached the Release Candidate stage.
> lindenlab / autobuild-1.1 
> bitbucket.org
> Hg repository hosted by Bitbucket.
>
>
>
> --
> OZ LINDEN | Engineering Director, Second Life
> email or hangouts: o...@lindenlab.com | Real Life: Scott Lawrence
> LINDEN LAB | Create Virtual Experiences 
>
>
> ___
> 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
>
>
>
>
> ___
> 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
>
___
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

Re: [opensource-dev] windows build issues

[Nicky Perian]

I have never used ssh://h...@bitbucket.org/NickyP/fs-autobuild-1.0. It was
put there for reference only.
This is what you should be using
https://bitbucket.org/lindenlab/autobuild-1.0

https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default=file-view-default#README-263

That is my dev setup and I was able to build a local FS with that setup.
But, I had already edited up to autobuild-1.1. That is only used in one
place at this line.
https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default=file-view-default#README-410


Change autobuild-1.1 to autobuild-1.0 and the instruction should work.

As is most often the case build instructions are a work in progress.


On Wed, Jan 4, 2017 at 7:15 AM, Lance Corrimal <lance.corri...@eregion.de>
wrote:

> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version
> autobuild 1.0
>
>
> d:\Users\lemmy\Build\autobuild-1.0>which autobuild
> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild
>
> d:\Users\lemmy\Build\autobuild-1.0>hg sum
> Vorgõnger: 728:7c36cb02fc10 tip
>  Search two directories up for package_override, we need this during the
> VS build steps.
> Zweig: default
> ▄bernehme: (clean)
> Aktualisiere: (aktuell)
>
> d:\Users\lemmy\Build\autobuild-1.0>hg in
> Vergleiche mit ssh://h...@bitbucket.org/NickyP/fs-autobuild-1.0
> Suche nach ─nderungen
> Keine ─nderungen gefunden
>
>
> Am 04.01.2017 um 13:46 schrieb Lance Corrimal:
> > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian:
> >> autobuild --version
> >>
> >> s/b 1.0 unless your on the viewer64 repo.
> >>
> > 64bit here.. using your autobuild, which used to work just fine before I
> > reinstalled my PC...
> >
> > ___
> > 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
>
>
___
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

Re: [opensource-dev] windows build issues

[Nicky Perian]

autobuild --version

s/b 1.0 unless your on the viewer64 repo.


On Wed, Jan 4, 2017 at 2:25 AM, Lance Corrimal 
wrote:

> Hi,
>
> I am in the process of rebuilding my windows build environment...
>
> [obvious steps removed]
>
> ... and what I get from autobuild configure is:
>
>
> CMake Error at cmake/Prebuilt.cmake:58 (message):
>   Failed to download or unpack prebuilt 'ogg_vorbis'.  Process returned %1
>   ist keine zulõssige Win32-Anwendung.
> Call Stack (most recent call first):
>   cmake/Audio.cmake:11 (use_prebuilt_binary)
>   cmake/LLAudio.cmake:3 (include)
>   llaudio/CMakeLists.txt:6 (include)
>
>
> looks to me as if i'm missing something, but what?
>
> ___
> 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
___
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

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

[Nicky Perian]

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
___
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

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

[Nicky Perian]

This is from viewer64 repo w/o changes.
0>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C2226: syntax error : unexpected type 'S'
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>  c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(52)
: see reference to class template instantiation 'LLResultTypeAdd'
being compiled
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C2226: syntax error : unexpected type 'S'
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
10>  c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(52)
: see reference to class template instantiation 'LLResultTypeAdd'
being compiled
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C3646: 'type_t' : unknown override specifier
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C3646: 'type_t' : unknown override specifier
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
1

I suspected that I had stepped on my source so started with a fresh clone.
This kicks off pages of the same error.

On Thu, Dec 22, 2016 at 9:22 AM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

> On 2016-12-22 09:58 , Nat Goodspeed wrote:
>
>
> In general, we have tried to isolate build artifacts under the
> build-whatever directory, in this case build-vc120-32 or build-vc120-64.
> That includes the libraries installed by autobuild: there should be
> separate build-vc120-32/packages and build-vc120-64/packages
> subdirectories. That separation should (!) also include CMake byproducts --
> though if indeed there's some unintentional crossover, I would suspect
> CMake stuff.
>
> Be alert for anything that's starting searches relative to the
> CMAKE_SOURC_DIR/..
>
>
> --
> OZ LINDEN | Engineering Director, Second Life
> email or hangouts: o...@lindenlab.com | Real Life: Scott Lawrence
> LINDEN LAB | Create Virtual Experiences 
>
___
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

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

[Nicky Perian]

I haven't confirmed, but there may be an issue with having build-vc120-32
and build-vc120-64 side by side and pickup of library dependencies when
switching from one build to the other.




On Wed, Dec 14, 2016 at 7:56 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> 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.
>>
>
> 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.
>
___
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

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

[Nicky Perian]

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







On Fri, Dec 9, 2016 at 4:11 AM, Henri Beauchamp <sl...@free.fr> wrote:

> On Thu, 8 Dec 2016 18:07:42 -0600, Nicky Perian wrote:
>
> > 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
>
___
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

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

[Nicky Perian]

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 <nickyper...@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) <
cal...@lindenlab.com> wrote:

> woohoo - thanks nicky.
>
> On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
>> *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/ca4ffedff48cf4a
>> e29622434567a59f6b010708b
>>
>> On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <
>> cal...@lindenlab.com> wrote:
>>
>>> 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.
>>>
>>>
>>>
>>> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>>>
>>>> On Dec 3, 2016 7:18 PM, "Nicky Perian" <nickyper...@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=ON2>&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
>>>

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

[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).*

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

On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> 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.
>
>
>
> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Dec 3, 2016 7:18 PM, "Nicky Perian" <nickyper...@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=ON2>&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. :-)
>>
>> ___
>> 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
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>
>
___
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

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

[Nicky Perian]

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=ON2>&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.






On Fri, Dec 2, 2016 at 9:25 AM, Nicky Perian <nickyper...@gmail.com> wrote:

> 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?
>
>
>
>
> On Wed, Nov 30, 2016 at 5:12 PM, Monty Brandenberg <mo...@lindenlab.com>
> wrote:
>
>> On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
>> >
>> > 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
>>
>
>
(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
Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified;
using the date and time (201612030806), which may not be unique
No windows64 configuration found; inheriting windows
-- Revision (from hg) 36447
-- Building 'Second Life Test' Version 4.1.3.36447
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
-- Copying redist libs for VC 12.0
-- Copying redist libs for VC 10.0
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
Copying icons for test
-- Configuring done
CMake Warning (dev) at media_plugins/libvlc/CMakeLists.txt:61 
(add_dependencies):
  Policy CMP0046 is not set: Error on non-existent dependency in
  add_dependencies.  Run "cmake --help-policy CMP0046" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  The dependency target "debug" of target "media_plugin_libvlc" 

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

[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?




On Wed, Nov 30, 2016 at 5:12 PM, Monty Brandenberg 
wrote:

> On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
> >
> > 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
>
___
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

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

[Nicky Perian]

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



On Wed, Nov 30, 2016 at 3:48 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> >> 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) <
> cal...@lindenlab.com> wrote:
>
>> 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.
>>
>> On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>>> 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
>>>
>>> On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed <n...@lindenlab.com>
>>> wrote:
>>>
>>>> On Nov 29, 2016 11:11 PM, "Nicky Perian" <nickyper...@gmail.com> wrote:
>>>>
>>>> > 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?
>>>>
>>>> I use:
>>>>
>>>> autobuild build --address-size=64
>>>>
>>>> :-)
>>>>
>>>> But I don't yet have a clean 64-bit build on any platform.
>>>>
>>>
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>>
>> CALLUM PRENTICE | Software Engineer
>>
>> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>
>>
>
>
___
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

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

[Nicky Perian]

>> 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) <
cal...@lindenlab.com> wrote:

> 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.
>
> On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
>> 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
>>
>> On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed <n...@lindenlab.com>
>> wrote:
>>
>>> On Nov 29, 2016 11:11 PM, "Nicky Perian" <nickyper...@gmail.com> wrote:
>>>
>>> > 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?
>>>
>>> I use:
>>>
>>> autobuild build --address-size=64
>>>
>>> :-)
>>>
>>> But I don't yet have a clean 64-bit build on any platform.
>>>
>>
>>
>> ___
>> 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
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/>
>
___
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

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

[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

On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Nov 29, 2016 11:11 PM, "Nicky Perian" <nickyper...@gmail.com> wrote:
>
> > 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?
>
> I use:
>
> autobuild build --address-size=64
>
> :-)
>
> But I don't yet have a clean 64-bit build on any platform.
>
___
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

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

[Nicky Perian]

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?



On Tue, Nov 29, 2016 at 8:37 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> 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.
>>
>
> 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.)
>
>
>> 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.
>
___
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

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

[Nicky Perian]

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.





On Thu, Nov 24, 2016 at 5:49 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> 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.
>
>
>
> On Thu, Nov 24, 2016 at 4:51 PM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>> 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>
>>
>
>
___
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

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

[Nicky Perian]

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.



On Thu, Nov 24, 2016 at 4:51 PM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian <nickyper...@gmail.com>
> wrote:
>
> 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/
> 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.
>
>
>> 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>
>
___
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

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

[Nicky Perian]

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

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

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

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

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

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

[Nicky Perian]

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


On Wed, Nov 23, 2016 at 10:06 AM, Nicky Perian <nickyper...@gmail.com>
wrote:

> Complete the record on opensource-dev.
>
> -- Forwarded message --
> From: Nicky Perian <nickyper...@gmail.com>
> Date: Wed, Nov 23, 2016 at 9:13 AM
> Subject: Re: 64 bit viewers build instructions
> To: Nat Goodspeed <n...@lindenlab.com>
> Cc: "Oz Linden (Scott Lawrence)" <o...@lindenlab.com>
>
>
> 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
>
>
> On Wed, Nov 23, 2016 at 8:43 AM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
>> On Wed, Nov 23, 2016 at 9:13 AM, Nat Goodspeed <n...@lindenlab.com> wrote:
>>
>> On Wed, Nov 23, 2016 at 9:04 AM, Nicky Perian <nickyper...@gmail.com>
>>> wrote:
>>>
>>>
>>>> For instance, the libraries for llphysicsextensions_stub need to be in
>>>>
>>>> http://automated-builds-secondlife-com.s3.amazonaws.com
>>>>
>>>> Instead of
>>>>
>>>> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/
>>>> ct2/467/985/
>>>>
>>>
>>> Sorry! I should be able to get you a new public build of
>>> llphysicsextensions_stub.
>>>
>>
>> https://bitbucket.org/lindenlab/viewer64/commits/4838e2cf369
>> 48f911b072a018f68f1be8c54eeba
>>
>
>
>
___
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

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

[Nicky Perian]

Complete the record on opensource-dev.

-- Forwarded message --
From: Nicky Perian <nickyper...@gmail.com>
Date: Wed, Nov 23, 2016 at 9:13 AM
Subject: Re: 64 bit viewers build instructions
To: Nat Goodspeed <n...@lindenlab.com>
Cc: "Oz Linden (Scott Lawrence)" <o...@lindenlab.com>


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\build-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\
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\packages\include\
openjpeg\openjpeg.h 94 1 llimagej2coj


On Wed, Nov 23, 2016 at 8:43 AM, Nat Goodspeed <n...@lindenlab.com> wrote:

> On Wed, Nov 23, 2016 at 9:13 AM, Nat Goodspeed <n...@lindenlab.com> wrote:
>
> On Wed, Nov 23, 2016 at 9:04 AM, Nicky Perian <nickyper...@gmail.com>
>> wrote:
>>
>>
>>> For instance, the libraries for llphysicsextensions_stub need to be in
>>>
>>> http://automated-builds-secondlife-com.s3.amazonaws.com
>>>
>>> Instead of
>>>
>>> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/ct2/467/985/
>>>
>>
>> Sorry! I should be able to get you a new public build of
>> llphysicsextensions_stub.
>>
>
> https://bitbucket.org/lindenlab/viewer64/commits/4838e2cf369
> 48f911b072a018f68f1be8c54eeba
>
___
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

Re: [opensource-dev] Darwin build failure

[Nicky Perian]

Yes please make a release. I'll one-off mac for this time. I filed a jira
and posted to the mailing list. autobuild at least on windows was backward
compatible. I was unable to get it to install properly on linux which is
not surprising given LL non-support of linux.

I saw this issue a few years ago and it was a not having llbase.py
installed.

I can't recall the solution, but it was simple.


On Wed, Nov 16, 2016 at 10:10 PM, Nicky Perian <nickyper...@gmail.com>
wrote:

> Failure:
> Mini:viewer-release nicky$ python --version
> Python 2.7.12
> Mini:viewer-release nicky$ /opt/local/Library/Frameworks/
> Python.framework/Versions/2.7/bin/autobuild configure -v -c
> RelWithDebInfoOS -- -DLL_TESTS:BOOL=OFF -DFMODEX:BOOL=ON -DOPENAL:BOOL=OFF
> -DPACKAGE:BOOL=ON -DQUICKTIME:BOOL=ON -DUSE_KDU:BOOL=OFF
> -DRELEASE_CRASH_REPORTING:BOOL=OFF
>
> Mini:viewer-release nicky$ /opt/local/Library/Frameworks/
> Python.framework/Versions/2.7/bin/autobuild build -c RelWithDebInfoOS
> 2>&1 |tee -a DarwinSL.log
> PhaseScriptExecution CMake\ PostBuild\ Rules /Users/nicky/viewer-release/
> build-darwin-i386/newview/SecondLife.build/RelWithDebInfo/secondlife-bin.
> build/Script-B5EAF7FE98AC47EB82B26BF7.sh
> cd /Users/nicky/viewer-release/indra
> /bin/sh -c /Users/nicky/viewer-release/build-darwin-i386/newview/
> SecondLife.build/RelWithDebInfo/secondlife-bin.build/Script-
> B5EAF7FE98AC47EB82B26BF7.sh
> /usr/bin/python /Users/nicky/viewer-release/indra/newview/viewer_manifest.py
> --actions=copy --arch=i386 --artwork=/Users/nicky/viewer-release/indra/newview
> --build=/Users/nicky/viewer-release/build-darwin-i386/newview
> --buildtype=RelWithDebInfo --configuration=RelWithDebInfo
> --dest=/Users/nicky/viewer-release/build-darwin-i386/newview/RelWithDebInfo/Second\
> Life.app --grid=agni --channel=Second\ Life\ Test
> --versionfile=/Users/nicky/viewer-release/build-darwin-
> i386/newview/viewer_version.txt --source=/Users/nicky/viewer-
> release/indra/newview
> Traceback (most recent call last):
>   File "/Users/nicky/viewer-release/indra/newview/viewer_manifest.py",
> line 47, in 
> from indra.base import llsd
> ImportError: No module named base
> make: *** [secondlife-bin_buildpart_0] Error 1
> Command /bin/sh failed with exit code 2
>
> ** BUILD FAILED **
>
>
> The following build commands failed:
> PhaseScriptExecution CMake\ PostBuild\ Rules /Users/nicky/viewer-release/
> build-darwin-i386/newview/SecondLife.build/RelWithDebInfo/secondlife-bin.
> build/Script-B5EAF7FE98AC47EB82B26BF7.sh
> (1 failure)
> ERROR: building configuration {'default': False, 'configure': {'command':
> None, 'options': ['-G', "'Xcode'"], 'filters': None, 'arguments': None},
> 'name': 'RelWithDebInfoOS', 'build': {'command': 'xcodebuild', 'options':
> ['-configuration RelWithDebInfo', '-project SecondLife.xcodeproj'],
> 'filters': None, 'arguments': None}} returned 65
> For more information: try re-running your command with --verbose or --debug
>
> This failure is from the removal of viewer python library files associated
> with MAINT-6585. With all MAINT-6585 reverted the build completes without
> error.
>
> Full paths for autobuild configure and build are used because of use of a
> bash script to build. The same error happens when building under Xcode.
>
> Windows and Linux use the same code and there are no errors.
>
> Has anyone else experienced this build failure?
>
> More importantly is there a correction.
>
> autobuild1.0 is used.
>
___
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

[opensource-dev] Darwin build failure

[Nicky Perian]

Failure:
Mini:viewer-release nicky$ python --version
Python 2.7.12
Mini:viewer-release nicky$
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/autobuild
configure -v -c RelWithDebInfoOS -- -DLL_TESTS:BOOL=OFF -DFMODEX:BOOL=ON
-DOPENAL:BOOL=OFF -DPACKAGE:BOOL=ON -DQUICKTIME:BOOL=ON -DUSE_KDU:BOOL=OFF
-DRELEASE_CRASH_REPORTING:BOOL=OFF

Mini:viewer-release nicky$
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/autobuild
build -c RelWithDebInfoOS 2>&1 |tee -a DarwinSL.log
PhaseScriptExecution CMake\ PostBuild\ Rules
/Users/nicky/viewer-release/build-darwin-i386/newview/SecondLife.build/RelWithDebInfo/secondlife-bin.build/Script-B5EAF7FE98AC47EB82B26BF7.sh
cd /Users/nicky/viewer-release/indra
/bin/sh -c
/Users/nicky/viewer-release/build-darwin-i386/newview/SecondLife.build/RelWithDebInfo/secondlife-bin.build/Script-B5EAF7FE98AC47EB82B26BF7.sh
/usr/bin/python
/Users/nicky/viewer-release/indra/newview/viewer_manifest.py --actions=copy
--arch=i386 --artwork=/Users/nicky/viewer-release/indra/newview
--build=/Users/nicky/viewer-release/build-darwin-i386/newview
--buildtype=RelWithDebInfo --configuration=RelWithDebInfo
--dest=/Users/nicky/viewer-release/build-darwin-i386/newview/RelWithDebInfo/Second\
Life.app --grid=agni --channel=Second\ Life\ Test
--versionfile=/Users/nicky/viewer-release/build-darwin-i386/newview/viewer_version.txt
--source=/Users/nicky/viewer-release/indra/newview
Traceback (most recent call last):
  File "/Users/nicky/viewer-release/indra/newview/viewer_manifest.py", line
47, in 
from indra.base import llsd
ImportError: No module named base
make: *** [secondlife-bin_buildpart_0] Error 1
Command /bin/sh failed with exit code 2

** BUILD FAILED **


The following build commands failed:
PhaseScriptExecution CMake\ PostBuild\ Rules
/Users/nicky/viewer-release/build-darwin-i386/newview/SecondLife.build/RelWithDebInfo/secondlife-bin.build/Script-B5EAF7FE98AC47EB82B26BF7.sh
(1 failure)
ERROR: building configuration {'default': False, 'configure': {'command':
None, 'options': ['-G', "'Xcode'"], 'filters': None, 'arguments': None},
'name': 'RelWithDebInfoOS', 'build': {'command': 'xcodebuild', 'options':
['-configuration RelWithDebInfo', '-project SecondLife.xcodeproj'],
'filters': None, 'arguments': None}} returned 65
For more information: try re-running your command with --verbose or --debug

This failure is from the removal of viewer python library files associated
with MAINT-6585. With all MAINT-6585 reverted the build completes without
error.

Full paths for autobuild configure and build are used because of use of a
bash script to build. The same error happens when building under Xcode.

Windows and Linux use the same code and there are no errors.

Has anyone else experienced this build failure?

More importantly is there a correction.

autobuild1.0 is used.
___
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

[opensource-dev] 64 bit lib archives

[Nicky Perian]

Starting to dabble a bit with p64_3p-zlib.
At autobuild build --address-size 32
getting:
../build-cmd.sh: line 44: AUTOBUILD_WIN_CMAKE_GEN: unbound variable


Any idea what I am doing wrong?
___
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

Re: [opensource-dev] Stuck on stupid

[Nicky Perian]

To complete the record.
Resolved.
*At:*
  add_custom_target(generate_breakpad_symbols DEPENDS
"${VIEWER_SYMBOL_FILE}" "${VIEWER_BINARY_NAME}" "${VIEWER_COPY_MANIFEST}")
*Added:*
*  MESSAGE( STATUS "dependencies:   " ${VIEWER_SYMBOL_FILE} "  "
${VIEWER_BINARY_NAME} "  " ${VIEWER_COPY_MANIFEST} " " )*
*  add_dependencies(generate_breakpad_symbols "${VIEWER_BINARY_NAME}")*
*Configured with*:
-DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE
*Result:*
*"${VIEWER_BINARY_NAME}"   *Had an extra space following that caused the
add_dependencies to fail.

*Then:*
configure with -DRELEASE_CRASH_REPORTING:BOOL=ON

and generate_breakpad_symbols project is included in the build.




On Fri, Jul 22, 2016 at 3:51 PM, Nicky Perian <nickyper...@gmail.com> wrote:

> I have done before and was surprised how simple it was. But...
>
> How do you tell the viewer build to provide the breakpad symbol generation
> in the build project?
>
> It should produce an archive of the symbols.
>
>
>
___
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

[opensource-dev] Stuck on stupid

[Nicky Perian]

I have done before and was surprised how simple it was. But...

How do you tell the viewer build to provide the breakpad symbol generation
in the build project?

It should produce an archive of the symbols.
___
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

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Nicky Perian]

Should avi abd wmv files be moved from cef to vlc plugin.
Made a change locally and it worked.


Movie (Windows Media WMV)


movie


media_plugin_libvlc




Movie (AVI)


movie


media_plugin_libvlc





On Sat, Jun 4, 2016 at 9:20 AM, Henri Beauchamp  wrote:

> On Sat, 4 Jun 2016 06:52:58 -0500, Argent Stonecutter wrote:
>
> >
> > > • Ask for help from open source developer community to
> > create a version for Linux using LibVLC
> >
> > Since Linux currently doesn’t use Quicktime, why doe it need to be
> > converted?
>
> Quicktime media plays just fine under Linux, thank you !...
>
> It needs to be converted for the sake of having an uniform set of plugins
> with the same capabilities on all OSes...
> Also, the gstreamer plugin, while working just fine (again, for Quicktime
> media included), would need the viewer code to be changed (it's doable
> hoewever) if it would be kept along other plugins (the new CEF3 plugin,
> without media textures flipping, and now the VLC plugin), since media
> textures are flipped upside down when compared to the old way of
> rendering them (which matched the gstreamer, the Quicktime and the
> QtWebkit plugins).
>
> 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
>
___
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

[opensource-dev] glib-networking and gstreamer stream processing.

[Nicky Perian]

This was not the SL viewer, I attempted to play an mp4 file that at one
time played without issue.

Messages logged:
  pid:27246: (media plugin) receiveMessage:1159: >Got size change
instruction from application with shm name: /LL27034_5 - size is 1 x 1
 pid:27246: (media plugin) receiveMessage:1175: *** Got size change with
matching shm, new size is 1 x 1
 pid:27246: (media plugin) receiveMessage:1176: *** Got size change with
matching shm, texture size size is 1 x 1
 pid:27246: (media plugin) processGSTEvents:306: GST error: TLS/SSL support
not available; install glib-networking
 pid:27246: (media plugin) processGSTEvents:306: GST error: Secure
connection setup failed.
 pid:27246: (media plugin) processGSTEvents:306: GST error: Internal data
flow error.
 pid:27246: (media plugin) processGSTEvents:306: GST error: Stream contains
no data.

When I did a package install of glib-networking the report was the newest
is already installed.

Does this require a module install?

LD_LIBRARY_PATH=${PWD}/lib64:/lib32 ldd
 bin/llplugin/libmedia_plugin_gstreamer.so

Does not show any missing dependencies.

Does anyone have experience with how glib-networking is linked or
installed?
___
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

Re: [opensource-dev] Firewall block of media files

[Nicky Perian]

After more thinking about it this must have been using gstreamer that
allowed direct play of mp4 mov etc. I'm busy with merging kokua up to v-r
tip for now, but will investigate over the weekend and post results
afterward.

On Thu, May 19, 2016 at 1:48 PM, Dax Dupont  wrote:

> Which is expected behavior, respecting MIME types should stay.
> On May 19, 2016 20:34, "Whirly Fizzle"  wrote:
>
>> That will not play in a web browser though, the file needs to be
>> downloaded to play it.
>> Being able to play dropbox links like that via MOAP never worked in any
>> SL viewer as far as I'm aware.
>>
>> --
>> Date: Thu, 19 May 2016 13:23:32 -0500
>> From: nickyper...@gmail.com
>> To: cal...@lindenlab.com
>> CC: opensource-dev@lists.secondlife.com
>> Subject: Re: [opensource-dev] Firewall block of media files
>>
>> URL placed in MOAP Texture
>> https://dl.dropboxusercontent.com/u/7833186/Horse.wmv
>>
>> This plays in windows media player and VLC installed on system.
>>
>>
>> Debug Log
>> 2016-05-19T17:45:41Z WARNING: LLToastAlertPanel::LLToastAlertPanel:
>> Alert: You have requested a file download, which is not supported within
>> Second Life.
>> 2016-05-19T17:45:43Z WARNING: LLToastAlertPanel::LLToastAlertPanel:
>> Alert: You have requested a file download, which is not supported within
>> Second Life.
>> 2016-05-19T17:45:44Z WARNING: LLToastAlertPanel::LLToastAlertPanel:
>> Alert: You have requested a file download, which is not supported within
>> Second Life.
>> 2016-05-19T17:45:47Z WARNING: LLToastAlertPanel::LLToastAlertPanel:
>> Alert: You have requested a file download, which is not supported within
>> Second Life.
>>
>> About SecondLife
>>
>> Second Life 4.0.4 (35251) May 18 2016 17:51:37 (Second Life Test)
>> Release Notes
>>
>> You are at 181.0, 69.0, 33.3 in Morris located at
>> sim9005.aditi.lindenlab.com (216.82.40.198:13006)
>> SLURL: secondlife://Aditi/secondlife/Morris/181/69/33
>> (global coordinates 255,413.0, 256,325.0, 33.3)
>> Second Life Server 16.04.21.314319
>> Retrieving...
>>
>> CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2498.54 MHz)
>> Memory: 8078 MB
>> OS Version: Microsoft Windows 8 64-bit  (Build 9200) compatibility mode.
>> real ver: 10.0 (Build 10011)
>> Graphics Card Vendor: NVIDIA Corporation
>> Graphics Card: GeForce GTX 970M/PCIe/SSE2
>>
>> Windows Graphics Driver Version: 10.18.0015.4281
>> OpenGL Version: 4.5.0 NVIDIA 365.10
>>
>> On Thu, May 19, 2016 at 11:57 AM, Callum Prentice (Callum) <
>> cal...@lindenlab.com> wrote:
>>
>> ​​
>> At one time we could play individual media files on both parcel media and
>> MOAP such as mov avi wmv that were stored on services such as Dropbox.
>> I noticed will testing viewer-release-vlc that it these are not allowed.
>>
>>
>> ​Can you elaborate what you mean by "not allowed" - they just don't play?
>>
>> If so, it might be that VLC doesn't support those media types.  I've
>> certainly been able to play MPEG4 files directly from Dropbox for example.
>>
>> ​
>>
>>
>>
>>
>> ___ 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
>>
>> ___
>> 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
>>
>
___
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

Re: [opensource-dev] Firewall block of media files

[Nicky Perian]

It may have been parcel media, but I remember them playing.

On Thu, May 19, 2016 at 1:34 PM, Whirly Fizzle 
wrote:

> That will not play in a web browser though, the file needs to be
> downloaded to play it.
> Being able to play dropbox links like that via MOAP never worked in any SL
> viewer as far as I'm aware.
>
> --
> Date: Thu, 19 May 2016 13:23:32 -0500
> From: nickyper...@gmail.com
> To: cal...@lindenlab.com
> CC: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Firewall block of media files
>
>
> URL placed in MOAP Texture
> https://dl.dropboxusercontent.com/u/7833186/Horse.wmv
>
> This plays in windows media player and VLC installed on system.
>
>
> Debug Log
> 2016-05-19T17:45:41Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> You have requested a file download, which is not supported within Second
> Life.
> 2016-05-19T17:45:43Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> You have requested a file download, which is not supported within Second
> Life.
> 2016-05-19T17:45:44Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> You have requested a file download, which is not supported within Second
> Life.
> 2016-05-19T17:45:47Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> You have requested a file download, which is not supported within Second
> Life.
>
> About SecondLife
>
> Second Life 4.0.4 (35251) May 18 2016 17:51:37 (Second Life Test)
> Release Notes
>
> You are at 181.0, 69.0, 33.3 in Morris located at
> sim9005.aditi.lindenlab.com (216.82.40.198:13006)
> SLURL: secondlife://Aditi/secondlife/Morris/181/69/33
> (global coordinates 255,413.0, 256,325.0, 33.3)
> Second Life Server 16.04.21.314319
> Retrieving...
>
> CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2498.54 MHz)
> Memory: 8078 MB
> OS Version: Microsoft Windows 8 64-bit  (Build 9200) compatibility mode.
> real ver: 10.0 (Build 10011)
> Graphics Card Vendor: NVIDIA Corporation
> Graphics Card: GeForce GTX 970M/PCIe/SSE2
>
> Windows Graphics Driver Version: 10.18.0015.4281
> OpenGL Version: 4.5.0 NVIDIA 365.10
>
> On Thu, May 19, 2016 at 11:57 AM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
> ​​
> At one time we could play individual media files on both parcel media and
> MOAP such as mov avi wmv that were stored on services such as Dropbox.
> I noticed will testing viewer-release-vlc that it these are not allowed.
>
>
> ​Can you elaborate what you mean by "not allowed" - they just don't play?
>
> If so, it might be that VLC doesn't support those media types.  I've
> certainly been able to play MPEG4 files directly from Dropbox for example.
>
> ​
>
>
>
>
> ___ 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
>
___
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

Re: [opensource-dev] Firewall block of media files

[Nicky Perian]

URL placed in MOAP Texture
https://dl.dropboxusercontent.com/u/7833186/Horse.wmv

This plays in windows media player and VLC installed on system.


Debug Log
2016-05-19T17:45:41Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
You have requested a file download, which is not supported within Second
Life.
2016-05-19T17:45:43Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
You have requested a file download, which is not supported within Second
Life.
2016-05-19T17:45:44Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
You have requested a file download, which is not supported within Second
Life.
2016-05-19T17:45:47Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
You have requested a file download, which is not supported within Second
Life.

About SecondLife

Second Life 4.0.4 (35251) May 18 2016 17:51:37 (Second Life Test)
Release Notes

You are at 181.0, 69.0, 33.3 in Morris located at
sim9005.aditi.lindenlab.com (216.82.40.198:13006)
SLURL: secondlife://Aditi/secondlife/Morris/181/69/33
(global coordinates 255,413.0, 256,325.0, 33.3)
Second Life Server 16.04.21.314319
Retrieving...

CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (2498.54 MHz)
Memory: 8078 MB
OS Version: Microsoft Windows 8 64-bit  (Build 9200) compatibility mode.
real ver: 10.0 (Build 10011)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 970M/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0015.4281
OpenGL Version: 4.5.0 NVIDIA 365.10

On Thu, May 19, 2016 at 11:57 AM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> ​​
>> At one time we could play individual media files on both parcel media and
>> MOAP such as mov avi wmv that were stored on services such as Dropbox.
>> I noticed will testing viewer-release-vlc that it these are not allowed.
>>
>
> ​Can you elaborate what you mean by "not allowed" - they just don't play?
>
> If so, it might be that VLC doesn't support those media types.  I've
> certainly been able to play MPEG4 files directly from Dropbox for example.
>
> ​
>
>
___
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

[opensource-dev] Firewall block of media files

[Nicky Perian]

At one time we could play individual media files on both parcel media and
MOAP such as mov avi wmv that were stored on services such as Dropbox.
I noticed will testing viewer-release-vlc that it these are not allowed.

There is a notice that these files cannot be downloaded to SecondLife.

How are we supposed to test media by file type if the individual true media
files (no wrappers) cannot be downloaded into secondlife grids?
___
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

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

[Nicky Perian]

https://jira.secondlife.com/browse/OPEN-151
Dated from when fmod went to fmodex
Kokua used gstreamer for streaming for windows, but went to fmodex because
of code being out of date with plugins.
Specfic to this was not playing some stream rates.

I could set Kokua back to gstreamer but would need to autobuild1.0 the
archives.

There is an overhead of the gstreamer plugins dll's. iirc it was about 25
MB.

Kokua still uses gstreamer for linux as a lot of the linux users want as
much opensource as possible.

Linux version relies on distro packages for the plugins.


On Mon, May 16, 2016 at 5:09 PM, Cinder Roxley 
wrote:

> On May 16, 2016 at 4:03:29 PM, Callum Prentice (Callum) (
> cal...@lindenlab.com) wrote:
>
>   Do you know if anyone has made a Windows or OS X version of it ?
>> ​
>>
>>
>> I made an attempt three years ago, got it working on OS X. Got frustrated
>> with mingw and moved on to something else. I know the Imprudence team had
>> some success with replacing both FMOD and Quicktime with gstreamer earlier
>> than that, but this issue from their tracker shows that they then debated
>> moving to FFMpeg or libvlc instead:
>> https://sourceforge.net/p/team-purple/imprudence/tickets/340/
>> ​
>>
>
> Good info - I'll go take a look - thanks Cinder.​
>  ​
>
> Looks like this is the last efforts on gstreamer for the viewer from
> Inworldz. Autobuild 3p for building gstreamer 1.0 win32:
> https://bitbucket.org/mccabe/3p-gstreamer-sdk-x86-iw
> --
> Cinder Roxley
> Sent with Airmail
>
>
> ___
> 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
>
___
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

[opensource-dev] Breakpad symbol tarball

[Nicky Perian]

How do you direct a build to produce a breakpad symbol tarball?

The python script is present, but I can't get it to run as part of a build.
___
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

[opensource-dev] USESYSTEMLIBS

[Nicky Perian]

Anyone building using system libs on a debian based distro. If so, do you
have a list of -dev packages to install? And, how are you handling the libs
that have no packages. jsoncpp glh-linear webkit hunspell to name a few.
___
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