From nickyperian at gmail.com Fri Dec 2 07:25:32 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 2 Dec 2016 09:25:32 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161202/8d77b5ab/attachment.htm From nickyperian at gmail.com Sat Dec 3 16:18:53 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 3 Dec 2016 18:18:53 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: With: (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log I get many: No windows64 configuration found; inheriting windows But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64 bit and it runs. vlc plugin had may unresolved externals so, commented it out in media-plugins CMakeLists.txt in order to complete the build. This was with viewer64-callum changes merged in. Attached is the configure log. On Fri, Dec 2, 2016 at 9:25 AM, Nicky Perian 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 > 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161203/a6c71311/attachment.htm -------------- next part -------------- (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" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_context-mt" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_context-mt-gd" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_coroutine-mt" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_coroutine-mt-gd" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_system-mt" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_system-mt-gd" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_thread-mt" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "libboost_thread-mt-gd" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. 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 "optimized" of target "media_plugin_libvlc" does not exist. This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done -- Build files have been written to: C:/Users/Bill/P64/viewer64/build-vc120-64 (autobuild-1.1) C:\Users\Bill\P64\viewer64> From nat at lindenlab.com Sat Dec 3 16:35:24 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Sat, 3 Dec 2016 19:35:24 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: With: (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log I get many: No windows64 configuration found; inheriting windows But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64 bit and it runs. Yes: we've been discussing those messages internally. The viewer's CMake logic runs autobuild install for each applicable package, and I think the messages you're seeing are simply from autobuild waking up each time and reading autobuild.xml. In other words, I believe the message is about the package_description rather than any of the installables. We really want to avoid duplicating all of the windows section of autobuild.xml for windows64, which is why we added $parameter support in autobuild 1.1. So we don't plan to add a windows64 section to package_description. vlc plugin had may unresolved externals so, commented it out in media-plugins CMakeLists.txt in order to complete the build. This was with viewer64-callum changes merged in. I'm pretty sure Callum disabled VLC too, though perhaps that's only local so far. We're really at about the same point! Please bear with us. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161203/0ae115ee/attachment.htm From callum at lindenlab.com Sat Dec 3 17:07:48 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Sat, 3 Dec 2016 17:07:48 -0800 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: 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 wrote: > On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: > > With: > (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 > configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE > -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE > -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log > > I get many: > > No windows64 configuration found; inheriting windows > > But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64 > bit and it runs. > > > Yes: we've been discussing those messages internally. The viewer's CMake > logic runs autobuild install for each applicable package, and I think the > messages you're seeing are simply from autobuild waking up each time and > reading autobuild.xml. In other words, I believe the message is about the > package_description rather than any of the installables. > > We really want to avoid duplicating all of the windows section of > autobuild.xml for windows64, which is why we added $parameter support in > autobuild 1.1. So we don't plan to add a windows64 section to > package_description. > > vlc plugin had may unresolved externals so, commented it out in > media-plugins CMakeLists.txt in order to complete the build. > > This was with viewer64-callum changes merged in. > > > I'm pretty sure Callum disabled VLC too, though perhaps that's only local > so far. > > We're really at about the same point! Please bear with us. :-) > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161203/42deba0e/attachment-0001.htm From nickyperian at gmail.com Sat Dec 3 17:12:31 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 3 Dec 2016 19:12:31 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: *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) < callum at 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 wrote: > >> On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: >> >> With: >> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 >> configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE >> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE >> -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log >> >> I get many: >> >> No windows64 configuration found; inheriting windows >> >> But, build-vc120-64/packages has 64 bit libraries and the viewer builds >> 64 bit and it runs. >> >> >> Yes: we've been discussing those messages internally. The viewer's CMake >> logic runs autobuild install for each applicable package, and I think the >> messages you're seeing are simply from autobuild waking up each time and >> reading autobuild.xml. In other words, I believe the message is about the >> package_description rather than any of the installables. >> >> We really want to avoid duplicating all of the windows section of >> autobuild.xml for windows64, which is why we added $parameter support in >> autobuild 1.1. So we don't plan to add a windows64 section to >> package_description. >> >> vlc plugin had may unresolved externals so, commented it out in >> media-plugins CMakeLists.txt in order to complete the build. >> >> This was with viewer64-callum changes merged in. >> >> >> I'm pretty sure Callum disabled VLC too, though perhaps that's only local >> so far. >> >> We're really at about the same point! Please bear with us. :-) >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161203/ea53ff46/attachment.htm From callum at lindenlab.com Sat Dec 3 17:32:36 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Sat, 3 Dec 2016 17:32:36 -0800 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: woohoo - thanks nicky. On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian 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/ > ca4ffedff48cf4ae29622434567a59f6b010708b > > On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) < > callum at 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 wrote: >> >>> On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: >>> >>> With: >>> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 >>> configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE >>> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE >>> -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log >>> >>> I get many: >>> >>> No windows64 configuration found; inheriting windows >>> >>> But, build-vc120-64/packages has 64 bit libraries and the viewer builds >>> 64 bit and it runs. >>> >>> >>> Yes: we've been discussing those messages internally. The viewer's CMake >>> logic runs autobuild install for each applicable package, and I think the >>> messages you're seeing are simply from autobuild waking up each time and >>> reading autobuild.xml. In other words, I believe the message is about the >>> package_description rather than any of the installables. >>> >>> We really want to avoid duplicating all of the windows section of >>> autobuild.xml for windows64, which is why we added $parameter support in >>> autobuild 1.1. So we don't plan to add a windows64 section to >>> package_description. >>> >>> vlc plugin had may unresolved externals so, commented it out in >>> media-plugins CMakeLists.txt in order to complete the build. >>> >>> This was with viewer64-callum changes merged in. >>> >>> >>> I'm pretty sure Callum disabled VLC too, though perhaps that's only >>> local so far. >>> >>> We're really at about the same point! Please bear with us. :-) >>> >>> _______________________________________________ >>> 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 >> > > -- CALLUM PRENTICE | Software Engineer LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161203/dd1d3296/attachment-0001.htm From sldev at free.fr Sun Dec 4 02:02:32 2016 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 4 Dec 2016 11:02:32 +0100 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: <20161204110232.384e412f788f7d0aec700f17@free.fr> On Sat, 3 Dec 2016 19:12:31 -0600, Nicky Perian wrote: > *only issue is that some script is trying to copy fmodex.dll Speaking of FMOD Ex, you might want to update it. The current version is v4.44.64 and got crash fixes over the one you are using... Henri. From nickyperian at gmail.com Thu Dec 8 16:07:42 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 8 Dec 2016 18:07:42 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: 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 # 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) < callum at lindenlab.com> wrote: > woohoo - thanks nicky. > > On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian > 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) < >> callum at 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 wrote: >>> >>>> On Dec 3, 2016 7:18 PM, "Nicky Perian" wrote: >>>> >>>> With: >>>> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 >>>> configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE >>>> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE >>>> -DFMODEX:BOOL=ON 2>&1 | c:\cygwin64\bin\tee configRel.log >>>> >>>> I get many: >>>> >>>> No windows64 configuration found; inheriting windows >>>> >>>> But, build-vc120-64/packages has 64 bit libraries and the viewer builds >>>> 64 bit and it runs. >>>> >>>> >>>> Yes: we've been discussing those messages internally. The viewer's >>>> CMake logic runs autobuild install for each applicable package, and I think >>>> the messages you're seeing are simply from autobuild waking up each time >>>> and reading autobuild.xml. In other words, I believe the message is about >>>> the package_description rather than any of the installables. >>>> >>>> We really want to avoid duplicating all of the windows section of >>>> autobuild.xml for windows64, which is why we added $parameter support in >>>> autobuild 1.1. So we don't plan to add a windows64 section to >>>> package_description. >>>> >>>> vlc plugin had may unresolved externals so, commented it out in >>>> media-plugins CMakeLists.txt in order to complete the build. >>>> >>>> This was with viewer64-callum changes merged in. >>>> >>>> >>>> I'm pretty sure Callum disabled VLC too, though perhaps that's only >>>> local so far. >>>> >>>> We're really at about the same point! Please bear with us. :-) >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > > > -- > > CALLUM PRENTICE | Software Engineer > > LINDEN LAB | Create Virtual Experiences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161208/a1dce262/attachment.htm From sldev at free.fr Fri Dec 9 02:11:41 2016 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 9 Dec 2016 11:11:41 +0100 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> Message-ID: <20161209111141.aeb9f636e48404c15d186243@free.fr> 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. From nickyperian at gmail.com Wed Dec 14 16:13:20 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 14 Dec 2016 18:13:20 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: <20161209111141.aeb9f636e48404c15d186243@free.fr> References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161214/11255d7a/attachment.htm From nat at lindenlab.com Wed Dec 14 17:56:00 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Wed, 14 Dec 2016 20:56:00 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> Message-ID: On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161214/150cdc1a/attachment.htm From callum at lindenlab.com Thu Dec 15 11:13:35 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Thu, 15 Dec 2016 11:13:35 -0800 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage Message-ID: https://jira.secondlife.com/browse/BUG-41029 I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and whilst it seems straightforward, it seems to be unraveling into something that touches dozens of files and I wondered if someone had done this work already. There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined indirectly here: https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 that are used to count memory sizes/usage/difference etc. I think we can convert them to their U64 equivalents for all viewers. Nat points out, rewriting this code using size_t as a return type would make more sense but that seems like it would involve more invasive code changes including changes in fundamental LL headers. What does the collective wisdom say? -- CALLUM PRENTICE | Software Engineer LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161215/26d88d9b/attachment.htm From desmoulins.uchi at googlemail.com Thu Dec 15 17:01:06 2016 From: desmoulins.uchi at googlemail.com (Niran) Date: Fri, 16 Dec 2016 02:01:06 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: Message-ID: Funny, i just so happened to stumble across this a few days ago when i had this mindblowing realization that this might be the cause for the Viewer not properly reporting VRAM over 4gb but i don't happen to have a 4+gb VRAM GPU so i wouldn't be able to test anything i do and ultimately dropped the idea of touching it for now. 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) : > https://jira.secondlife.com/browse/BUG-41029 > > I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and > whilst it seems straightforward, it seems to be unraveling into something > that touches dozens of files and I wondered if someone had done this work > already. > > There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined > indirectly here: > > https://bitbucket.org/lindenlab/viewer64/src/ > 9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/ > llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 > > that are used to count memory sizes/usage/difference etc. I think we can > convert them to their U64 equivalents for all viewers. > > Nat points out, rewriting this code using size_t as a return type would > make more sense but that seems like it would involve more invasive code > changes including changes in fundamental LL headers. > > What does the collective wisdom say? > > -- > > CALLUM PRENTICE | Software Engineer > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161216/0d36d922/attachment.htm From callum at lindenlab.com Thu Dec 15 17:03:53 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Thu, 15 Dec 2016 17:03:53 -0800 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: Message-ID: Yep - I saw a lot of memory related texture references too - I don't know if cards these days have more than 4GB of video memory - definitely a possibility soon if not already. On Thu, Dec 15, 2016 at 5:01 PM, Niran wrote: > Funny, i just so happened to stumble across this a few days ago when i had > this mindblowing realization that this might be the cause for the Viewer > not properly reporting VRAM over 4gb but i don't happen to have a 4+gb VRAM > GPU so i wouldn't be able to test anything i do and ultimately dropped the > idea of touching it for now. > > 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) > : > >> https://jira.secondlife.com/browse/BUG-41029 >> >> I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and >> whilst it seems straightforward, it seems to be unraveling into something >> that touches dozens of files and I wondered if someone had done this work >> already. >> >> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >> defined indirectly here: >> >> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9 >> c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h? >> at=default&fileviewer=file-view-default#llunittype.h-824 >> >> that are used to count memory sizes/usage/difference etc. I think we >> can convert them to their U64 equivalents for all viewers. >> >> Nat points out, rewriting this code using size_t as a return type would >> make more sense but that seems like it would involve more invasive code >> changes including changes in fundamental LL headers. >> >> What does the collective wisdom say? >> >> -- >> >> CALLUM PRENTICE | Software Engineer >> >> 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 > -- CALLUM PRENTICE | Software Engineer LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161215/9082d7b6/attachment.htm From desmoulins.uchi at googlemail.com Thu Dec 15 17:12:17 2016 From: desmoulins.uchi at googlemail.com (Niran) Date: Fri, 16 Dec 2016 02:12:17 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: Message-ID: They do, the new ones at least, up to 8gb and possibly more already. But then i think using more than 4gb is currently useless anyway, the Viewer can hardly handle 1992mb (currently tested) for both Texture and Scene memory coming up to a total of roughly 4gb. On top of that if you're talking about RAM usage, it shouldn't be a problem either, the Viewer memory display is obsolete anyway and always was kinda wrong and/or lining up with what the task manager was showing. If you want to check memory usage you would naturally use the task manager anyway. I fear though that it might be used somewhere and could potentially lead to faulty memory handling behavior, like when a feature asks for the memory usage to start preventive measures (like we had long ago with the auto close after 30 seconds when memory usage went too high). Other than that i see no reason to fix a wrong memory display as it is just that, a display, information no one except maybe skilled render coders are ever going to use but then again i see no reason not to fix it. If you get the chance to do it, you should go ahead and fix it, as side project maybe so it doesn't interfere with your current projects. 2016-12-16 2:03 GMT+01:00 Callum Prentice (Callum) : > Yep - I saw a lot of memory related texture references too - I don't know > if cards these days have more than 4GB of video memory - definitely a > possibility soon if not already. > > On Thu, Dec 15, 2016 at 5:01 PM, Niran > wrote: > >> Funny, i just so happened to stumble across this a few days ago when i >> had this mindblowing realization that this might be the cause for the >> Viewer not properly reporting VRAM over 4gb but i don't happen to have a >> 4+gb VRAM GPU so i wouldn't be able to test anything i do and ultimately >> dropped the idea of touching it for now. >> >> 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) > >: >> >>> https://jira.secondlife.com/browse/BUG-41029 >>> >>> I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and >>> whilst it seems straightforward, it seems to be unraveling into something >>> that touches dozens of files and I wondered if someone had done this work >>> already. >>> >>> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >>> defined indirectly here: >>> >>> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9 >>> c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at= >>> default&fileviewer=file-view-default#llunittype.h-824 >>> >>> that are used to count memory sizes/usage/difference etc. I think we >>> can convert them to their U64 equivalents for all viewers. >>> >>> Nat points out, rewriting this code using size_t as a return type would >>> make more sense but that seems like it would involve more invasive code >>> changes including changes in fundamental LL headers. >>> >>> What does the collective wisdom say? >>> >>> -- >>> >>> CALLUM PRENTICE | Software Engineer >>> >>> 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 >> > > > > -- > > CALLUM PRENTICE | Software Engineer > > LINDEN LAB | Create Virtual Experiences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161216/d47601a8/attachment-0001.htm From cinder at alchemyviewer.org Thu Dec 15 17:16:11 2016 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Fri, 16 Dec 2016 01:16:11 +0000 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: Message-ID: <0100015905336638-ad039b37-a881-4b58-ae0f-54d82580825e-000000@email.amazonses.com> Mine has 6GB and was relatively inexpensive ($211 USD) As far as the viewer, I think the best way to go would be to bite the bullet and rework those to use size_t.? --? Cinder Roxley Sent with Airmail On December 15, 2016 at 7:03:58 PM, Callum Prentice (Callum) (callum at lindenlab.com ) wrote: Yep - I saw a lot of memory related texture references too - I don't know if cards these days have more than 4GB of video memory - definitely a possibility soon if not already. On Thu, Dec 15, 2016 at 5:01 PM, Niran > wrote: Funny, i just so happened to stumble across this a few days ago when i had this mindblowing realization that this might be the cause for the Viewer not properly reporting VRAM over 4gb but i don't happen to have a 4+gb VRAM GPU so i wouldn't be able to test anything i do and ultimately dropped the idea of touching it for now. 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) >: https://jira.secondlife.com/browse/BUG-41029 I'm taking a look at?https://jira.secondlife.com/browse/BUG-41029and whilst it seems straightforward, it seems to be unraveling into something that touches dozens of files and I wondered if someone had done this work already. There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined indirectly here:? https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 that are used to count memory sizes/usage/difference etc. ?I think we can convert them to their U64 equivalents for all viewers.? Nat points out, rewriting this code using size_t as a return type would make more sense but that seems like it would involve more invasive code changes including changes in fundamental LL headers. What does the collective wisdom say? --? CALLUM PRENTICE | Software Engineer 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 -- CALLUM PRENTICE | Software Engineer 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161216/9eaf37f0/attachment.htm From sldev at free.fr Fri Dec 16 00:44:51 2016 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 16 Dec 2016 09:44:51 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: Message-ID: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote: > https://jira.secondlife.com/browse/BUG-41029 > > .../... > > There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined > indirectly here: > > https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 > > that are used to count memory sizes/usage/difference etc. I think we can > convert them to their U64 equivalents for all viewers. > > Nat points out, rewriting this code using size_t as a return type would > make more sense but that seems like it would involve more invasive code > changes including changes in fundamental LL headers. > > What does the collective wisdom say? My *personal* wisdom says that this U32Bytes/U32Megabytes templatized thingy is just the expression of the lazyness of its coder (frankly, is it *that* difficult to use a constant multiplier to convert from bytes to megabytes ?) and just adds more complexity to the generated code without any benefit whatsoever. As a result, I did not backport this non-sense to the Cool VL Viewer and kept everything in normal variables (U32 for megabytes, U64 for bytes, etc), using constants to convert from one unit to the other when needed; my viewer is therefore unafffected by that bug... My advice would therefore be to revert the corresponding commit. Henri. From sldev at free.fr Fri Dec 16 01:16:01 2016 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 16 Dec 2016 10:16:01 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> References: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> Message-ID: <20161216101601.df95edb5f3b70b2e60ada1db@free.fr> On Fri, 16 Dec 2016 09:44:51 +0100, Henri Beauchamp wrote: > my viewer is therefore unafffected by that bug... In fact, I had a doubt and checked: it was affected, but the fix took me exactly 3 minutes to perform (4 static variables in LLImageGL and LLViewerTexture that were S32 integers and that I made into S64 ones): compared to what it will take you to edit the templatized names in all files, I'd say that the demonstration of how templates can actually harm the maintainability of the code is done... Henri. From monty at lindenlab.com Fri Dec 16 07:07:45 2016 From: monty at lindenlab.com (Monty Brandenberg) Date: Fri, 16 Dec 2016 10:07:45 -0500 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: <20161216101601.df95edb5f3b70b2e60ada1db@free.fr> References: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> <20161216101601.df95edb5f3b70b2e60ada1db@free.fr> Message-ID: <47afabce-6081-04b5-988d-a8436a1be904@lindenlab.com> On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > I'd say that the demonstration of how templates can actually > harm the maintainability of the code is done... Hahaha, that is a permanent on-going debate. m From sldev at free.fr Fri Dec 16 08:46:07 2016 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 16 Dec 2016 17:46:07 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: <47afabce-6081-04b5-988d-a8436a1be904@lindenlab.com> References: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> <20161216101601.df95edb5f3b70b2e60ada1db@free.fr> <47afabce-6081-04b5-988d-a8436a1be904@lindenlab.com> Message-ID: <20161216174607.43a998bf79112e9b5a35e559@free.fr> On Fri, 16 Dec 2016 10:07:45 -0500, Monty Brandenberg wrote: > On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > > > I'd say that the demonstration of how templates can actually > > harm the maintainability of the code is done... > > Hahaha, that is a permanent on-going debate. I said *can harm*, not *always harm*... There are very appropriate and efficient uses of templates, but the one in question is not (it's more like using a hammer and an anvil to squash a bug). :-) Henri. From richard at lindenlab.com Fri Dec 16 11:14:59 2016 From: richard at lindenlab.com (Richard Nelson) Date: Fri, 16 Dec 2016 11:14:59 -0800 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> References: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> Message-ID: FWIW, those particular units types were introduced as part of the LLTrace metrics update and found several cases where the incorrect units were being recorded, resulting in skewed/invalid metrics. The point is not that it is hard to multiply by a constant to do unit conversion...it is that programmers sometimes forget to, so it is hard to know how much you can trust metrics that have not been thoroughly vetted in the code. On Fri, 16 Dec 2016 00:44:51 -0800, Henri Beauchamp wrote: > On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote: > >> https://jira.secondlife.com/browse/BUG-41029 >> >> .../... >> >> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >> defined >> indirectly here: >> >> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 >> >> that are used to count memory sizes/usage/difference etc. I think we >> can >> convert them to their U64 equivalents for all viewers. >> >> Nat points out, rewriting this code using size_t as a return type would >> make more sense but that seems like it would involve more invasive code >> changes including changes in fundamental LL headers. >> >> What does the collective wisdom say? > > My *personal* wisdom says that this U32Bytes/U32Megabytes templatized > thingy is just the expression of the lazyness of its coder (frankly, > is it *that* difficult to use a constant multiplier to convert from > bytes to megabytes ?) and just adds more complexity to the generated > code without any benefit whatsoever. > > As a result, I did not backport this non-sense to the Cool VL Viewer > and kept everything in normal variables (U32 for megabytes, U64 for > bytes, etc), using constants to convert from one unit to the other > when needed; my viewer is therefore unafffected by that bug... > > My advice would therefore be to revert the corresponding commit. > > 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 -- Festina Lente From sldev at free.fr Sat Dec 17 01:48:00 2016 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 17 Dec 2016 10:48:00 +0100 Subject: [opensource-dev] Question about BUG-41029 and 64 bit usage In-Reply-To: References: <20161216094451.fd92ff7bb7eb0ad066a5a7fd@free.fr> Message-ID: <20161217104800.9581d72e5919c313eebeb9f8@free.fr> On Fri, 16 Dec 2016 11:14:59 -0800, Richard Nelson wrote: > FWIW, those particular units types were introduced as part of the LLTrace > metrics update and found several cases where the incorrect units were > being recorded, resulting in skewed/invalid metrics. The point is not > that it is hard to multiply by a constant to do unit conversion...it is > that programmers sometimes forget to, so it is hard to know how much you > can trust metrics that have not been thoroughly vetted in the code. The guy with the anvil and the hammmer had a good reason too. :-D I would have solved this issue differently, e.g. by ensuring all variables used in the viewer code classes to track down memory usage use the same "unit" (more like a multiple, here), such as bytes in S64 variables (or kilobytes in S32), then also making sure all those variables names bear the unit (multiple) name in their own name (e.g.: mTextureMemoryBytes). With a comment or two in appropriate locations in the stats sending methods, stating what units are to be used, this would have covered both current and future usages of memory tracking for coders. Henri. From nickyperian at gmail.com Thu Dec 22 05:29:44 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 22 Dec 2016 07:29:44 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> Message-ID: 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 wrote: > On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/9df10e28/attachment.htm From nat at lindenlab.com Thu Dec 22 06:58:21 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 22 Dec 2016 09:58:21 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> Message-ID: On Thu, Dec 22, 2016 at 8:29 AM, Nicky Perian wrote: 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. > Please let us know what you find out. 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. Don't be dismayed if, when you post your findings, we don't respond right away: today is the last day before Linden's holiday break. We'll be back online, much refreshed, on Tuesday, January 3rd. Merry Christmas! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/a36df96e/attachment.htm From oz at lindenlab.com Thu Dec 22 07:22:18 2016 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 22 Dec 2016 10:22:18 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> Message-ID: <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> 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: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/d202afa1/attachment.htm From nickyperian at gmail.com Thu Dec 22 09:21:37 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 22 Dec 2016 11:21:37 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: 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) < oz at 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: oz at lindenlab.com | Real Life: Scott Lawrence > LINDEN LAB | Create Virtual Experiences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/35f7c6e2/attachment-0001.htm From nat at lindenlab.com Thu Dec 22 09:32:25 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 22 Dec 2016 12:32:25 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: On Thu, Dec 22, 2016 at 12:21 PM, Nicky Perian wrote: 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) > Okay. We're trying to unify compile switches across libraries and viewer builds, so we've introduced https://bitbucket.org/lindenlab/viewer-build-variables rather than trying to keep compile switches in sync by hand, which has historically been troublesome. The idea is that you clone that repo locally, then set environment variable AUTOBUILD_VARIABLES_FILE to the 'variables' file within your local viewer-build-variables clone. This provides switches and macro definitions that we've previously set in indra/cmake/00-Common.cmake. In fact I recently pulled the LL_BUILD environment variable (set by autobuild source_environment when AUTOBUILD_VARIABLES_FILE is set) into the CMake logic, and eliminated the switches within 00-Common.cmake now made redundant by the switches in LL_BUILD. Among those switches is /DLL_WINDOWS. At this point, if you don't have AUTOBUILD_VARIABLES_FILE pointing to your local viewer-build-variables/variables file, you won't have LL_WINDOWS set. Without LL_WINDOWS, you don't get LL_TYPEOF() defined. Without LL_TYPEOF(), you get those strange errors. Naturally we'll be updating all the public documentation to reflect these things... but we're still evolving all this stuff! Sorry, but by tracking the bleeding edge of our development, you might occasionally get nicked. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/f5137fab/attachment.htm From nickyperian at gmail.com Thu Dec 22 11:24:35 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 22 Dec 2016 13:24:35 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161222/3c7aea4d/attachment.htm From nat at lindenlab.com Thu Dec 22 12:51:08 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 22 Dec 2016 15:51:08 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian 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! From bogus@does.not.exist.com Mon Dec 19 13:49:02 2016 From: bogus@does.not.exist.com () Date: Mon, 19 Dec 2016 21:49:02 -0000 Subject: No subject Message-ID: 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-bounces at lists.secondlife.com > > on behalf of Lance Corrimal > > *Sent:* 04 January 2017 14:12 > *To:* Oz Linden (Scott Lawrence); opensource-dev at 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: oz at 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 > --001a114f7dcc13392a0545495e19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
cd into local repo =C2=A0firestorm, viewer-release are any= other.
From there enter autobuild --version =C2=A0an absolute path sho= uld 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=3D'patht= oautobuild/bin/autobuild' environment variable.




On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal <Lance.Corrimal at eregion.de> wrote:
=20 =20 =20

that's what i'm using. Like I said already, I had to reinsta= ll 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 1= 9:15 schrieb Whirly Fizzle:
=20 =20

If you are building Firestorm 64bit, you must use Nicky Dasmijn's autobuild: https://bitbucket.org/NickyD/autobuild-1.0

NickyD / autobuild-1.0
bitb= ucket.org
Hg repository hosted by Bitbucket.



From: opensource-dev-bounces at lists.secondlife.com &= lt;opensource-dev-bounces at lists.secondlife.com> on behalf of Lance Corrimal <Lance.Corrimal at eregion.de>
Sent: 04 January 2017 14:12
To: Oz Linden (Scott Lawrence); openso= urce-dev at lists.secondlife.com
Subject: Re: [opensource-dev] windows build issues
=C2=A0

actually I'm building the firestorm developer version, and that used to work just fine until I reinstalled my PC yesterday ;_;


Am 04.01.2= 017 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=20
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 / autobu= ild-1.1
bitbucket.org
Hg repository hosted by Bitbucket.



--
OZ LINDEN | Engineering Director, Second Life
email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence
= LINDEN LAB | Create Virtual Experiences 


_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondl=
ife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privile=
ges



_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privile= ges

--001a114f7dcc13392a0545495e19-- From bogus@does.not.exist.com Mon Dec 19 13:49:02 2016 From: bogus@does.not.exist.com () Date: Mon, 19 Dec 2016 21:49:02 -0000 Subject: No subject Message-ID: 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 * 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 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://hg at 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=3Ddefault&fileviewer=3Dfile-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=3Ddefault&fileviewer=3Dfile-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 > 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=C3=B5nger: 728:7c36cb02fc10 tip >> Search two directories up for package_override, we need this during the >> VS build steps. >> Zweig: default >> =E2=96=84bernehme: (clean) >> Aktualisiere: (aktuell) >> >> d:\Users\lemmy\Build\autobuild-1.0>hg in >> Vergleiche mit ssh://hg at bitbucket.org/NickyP/fs-autobuild-1.0 >> Suche nach =E2=94=80nderungen >> Keine =E2=94=80nderungen 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 >> >> > > --f403045f8b5870d5e1054557a2c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 5, 2= 017 at 1:45 AM, Lance Corrimal <Lance.Corrimal at eregion.de><= /span> wrote:
=20 =20 =20

Does that autobuild in https://bitbuc= ket.org/lindenlab/autobuild-1.0 support -m64?


Am 04.01.2017 um 1= 6:06 schrieb Nicky Perian:
I have never used=C2=A0ssh://hg at bitbuc= ket.org/NickyP/fs-autobuild-1.0. It was put there for reference only.
This is what you should be using=C2=A0https://bitbucket.org/<= wbr>lindenlab/autobuild-1.0


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.

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.Corrimal at 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<= br>
d:\Users\lemmy\Build\autobuild-1.0>hg sum
Vorg=C3=B5nger: 728:7c36cb02fc10 tip
=C2=A0Search two directories up for package_override, we need this during the
VS build steps.
Zweig: default
=E2=96=84bernehme: (clean)
Aktualisiere: (aktuell)

d:\Users\lemmy\Build\autobuild-1.0>hg in
Vergleiche mit ssh://hg at bitbucket.org/Nic= kyP/fs-autobuild-1.0
Suche nach =E2=94=80nderungen
Keine =E2=94=80nderungen 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




--f403045f8b5870d5e1054557a2c7--