From nickyperian at gmail.com Wed Nov 16 20:10:07 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 16 Nov 2016 22:10:07 -0600 Subject: [opensource-dev] Darwin build failure Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161116/a6b0dd9d/attachment.htm From nickyperian at gmail.com Thu Nov 17 02:41:25 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 17 Nov 2016 04:41:25 -0600 Subject: [opensource-dev] Darwin build failure In-Reply-To: References: Message-ID: 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161117/656c0300/attachment.htm From oz at lindenlab.com Tue Nov 22 06:01:45 2016 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 22 Nov 2016 09:01:45 -0500 Subject: [opensource-dev] Darwin build failure In-Reply-To: References: Message-ID: On 2016-11-17 05:41 , Nicky Perian wrote: > > 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. > pip install llbase -- 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/20161122/e8aed412/attachment.htm From oz at lindenlab.com Tue Nov 22 06:26:04 2016 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 22 Nov 2016 09:26:04 -0500 Subject: [opensource-dev] 64 bit lib archives In-Reply-To: References: Message-ID: <4b3a6194-efdf-33d3-f598-7497d52cdd19@lindenlab.com> On 2016-10-26 18:17 , Nicky Perian wrote: > 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? We do plan to document this on the wiki soon - we've been waiting until we've successfully built the viewer in the new structure (we're close!). As part of the 64 bit project, we've been revamping a bunch of the build infrastructure to make it easier to build large numbers of related projects with common options. The key to this is that we've added a new argument to the autobuild source_environment subcommand: usage: autobuild source_environment [-h] [-V] [-n] [-q] [-v] [-d] [-p PLATFORM] [-A {32,64}] [varsfile] [BUILDTYPE] prints out the shell environment for Autobuild-based buildscripts to use (by calling 'eval' i.e. eval "$(autobuild source_environment)"). positional arguments: varsfile Local sh script in which to find essential environment variable settings (default from $AUTOBUILD_VARIABLES_FILE), e.g. a checkout of https://bitbucket.org/lindenlab/viewer-build- variables/src/tip/variables BUILDTYPE Release, RelWithDebInfo or Debug [no default]: if specified, requests shortened names for LL_BUILD environment variables specific to this BUILDTYPE optional arguments: -h, --help show this help message and exit -V, --version show program's version number and exit -n, --dry-run run tool in dry run mode if available -q, --quiet minimal output -v, --verbose verbose output -d, --debug debug output -p PLATFORM, --platform PLATFORM may only be the current platform or "common" (useful for source packages) -A {32,64}, --address-size {32,64} specify address size (modifies platform) To use this, check out a copy of the viewer-build-variables repository: https://bitbucket.org/lindenlab/viewer-build-variables and set the environment variable AUTOBUILD_VARIABLES_FILE to point to viewer-build-variables/variables. -- 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/20161122/f1139858/attachment.htm From nickyperian at gmail.com Wed Nov 23 08:06:58 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 23 Nov 2016 10:06:58 -0600 Subject: [opensource-dev] Fwd: 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: Complete the record on opensource-dev. ---------- Forwarded message ---------- From: Nicky Perian Date: Wed, Nov 23, 2016 at 9:13 AM Subject: Re: 64 bit viewers build instructions To: Nat Goodspeed Cc: "Oz Linden (Scott Lawrence)" 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 wrote: > On Wed, Nov 23, 2016 at 9:13 AM, Nat Goodspeed wrote: > > On Wed, Nov 23, 2016 at 9:04 AM, Nicky Perian >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161123/0a60d54c/attachment.htm From nickyperian at gmail.com Wed Nov 23 09:24:13 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 23 Nov 2016 11:24:13 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 wrote: > Complete the record on opensource-dev. > > ---------- Forwarded message ---------- > From: Nicky Perian > Date: Wed, Nov 23, 2016 at 9:13 AM > Subject: Re: 64 bit viewers build instructions > To: Nat Goodspeed > Cc: "Oz Linden (Scott Lawrence)" > > > 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 wrote: > >> On Wed, Nov 23, 2016 at 9:13 AM, Nat Goodspeed wrote: >> >> On Wed, Nov 23, 2016 at 9:04 AM, Nicky Perian >>> 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161123/2c4f9bd5/attachment-0001.htm From nat at lindenlab.com Wed Nov 23 10:11:02 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Wed, 23 Nov 2016 13:11:02 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian wrote: This is on a Release. The solution defaulted to Debug and I failed to > notice. > So, that raises the question; Why when autobuild source_environment is set > to Release did it not follow through to the soultion? > There is a program called VSTool in indra/tools/vstool that has been used to postprocess the .sln file generated by autobuild configure (running CMake). We recently stopped running that implicitly, for a couple reasons: 1. VSTool began failing intermittently on our build machines, impacting the reliability of our build farm. But VSTool's only function is to set defaults for the IDE -- which is completely irrelevant to an unattended build! So for an official build-farm build, the only effect of running VSTool was the negative one of introducing intermittent failures. It can take an hour to rerun a full official build-farm build. 2. VSTool was being run in a weird way, with '&&' being passed by autobuild.xml as a command argument. - That relied on autobuild invoking commands through the shell. autobuild-1.1 has recently started invoking commands directly *without* using the shell, which in general is more robust and secure. But that meant that '&&' and 'VSTool.exe' and its args were being passed to devenv as additional arguments. Of course devenv was completely nonplussed. - autobuild.xml is not a scripting language. It has no way to invoke VSTool conditionally. We couldn't run it only for interactive developer builds. The *right* fix is for CMake to generate the .sln (etc.) files with the appropriate defaults already set. Until we get that, if your workflow involves autobuild configure followed by a Visual Studio IDE session, please run autobuild configure in a shell script that also runs VSTool with the arguments you've seen in previous versions of autobuild.xml. > Error 7 error LNK1181: cannot open input file > '..\llimagej2coj\Release\llimagej2coj.lib' C:\Users\Bill\P64\viewer64\bui > ld-vc120-32\newview\LINK secondlife-bin > Error 4 error C2039: 'page_zoom_factor' : is not a member of > 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind > ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef > Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such > file or directory C:\Users\Bill\P64\viewer64\bui > ld-vc120-32\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj > I jumped right in trying to build a 64-bit Windows viewer. Your mail prompted me to circle back and clean up the 32-bit Windows build of lindenlab/viewer64. I see these errors and am working on them. (I think I've already worked around the LLCEFLibSettings one.) Please stay tuned! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161123/e0f8f79a/attachment.htm From nickyperian at gmail.com Thu Nov 24 11:19:21 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 24 Nov 2016 13:19:21 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 wrote: > On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian > wrote: > > This is on a Release. The solution defaulted to Debug and I failed to >> notice. >> So, that raises the question; Why when autobuild source_environment is >> set to Release did it not follow through to the soultion? >> > > There is a program called VSTool in indra/tools/vstool that has been used > to postprocess the .sln file generated by autobuild configure (running > CMake). We recently stopped running that implicitly, for a couple reasons: > > > 1. VSTool began failing intermittently on our build machines, > impacting the reliability of our build farm. But VSTool's only function is > to set defaults for the IDE -- which is completely irrelevant to an > unattended build! So for an official build-farm build, the only effect of > running VSTool was the negative one of introducing intermittent failures. > It can take an hour to rerun a full official build-farm build. > 2. VSTool was being run in a weird way, with '&&' being passed by > autobuild.xml as a command argument. > - That relied on autobuild invoking commands through the shell. > autobuild-1.1 has recently started invoking commands directly > *without* using the shell, which in general is more robust and > secure. But that meant that '&&' and 'VSTool.exe' and its args were being > passed to devenv as additional arguments. Of course devenv was completely > nonplussed. > - autobuild.xml is not a scripting language. It has no way to > invoke VSTool conditionally. We couldn't run it only for interactive > developer builds. > > > The *right* fix is for CMake to generate the .sln (etc.) files with the > appropriate defaults already set. > > Until we get that, if your workflow involves autobuild configure followed > by a Visual Studio IDE session, please run autobuild configure in a shell > script that also runs VSTool with the arguments you've seen in previous > versions of autobuild.xml. > > >> Error 7 error LNK1181: cannot open input file >> '..\llimagej2coj\Release\llimagej2coj.lib' C:\Users\Bill\P64\viewer64\bui >> ld-vc120-32\newview\LINK secondlife-bin >> Error 4 error C2039: 'page_zoom_factor' : is not a member of >> 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind >> ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef >> Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such >> file or directory C:\Users\Bill\P64\viewer64\bui >> ld-vc120-32\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj >> > > I jumped right in trying to build a 64-bit Windows viewer. Your mail > prompted me to circle back and clean up the 32-bit Windows build of > lindenlab/viewer64. I see these errors and am working on them. (I think > I've already worked around the LLCEFLibSettings one.) > > Please stay tuned! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161124/ff38405e/attachment.htm From nat at lindenlab.com Thu Nov 24 14:51:45 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 24 Nov 2016 17:51:45 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161124/3acc2a94/attachment.htm From nickyperian at gmail.com Thu Nov 24 15:49:41 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 24 Nov 2016 17:49:41 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 wrote: > On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161124/1d36573b/attachment.htm From nickyperian at gmail.com Sat Nov 26 20:37:54 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 26 Nov 2016 22:37:54 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 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 wrote: > >> On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161126/6165f1e5/attachment.htm From nat at lindenlab.com Tue Nov 29 18:37:54 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Tue, 29 Nov 2016 21:37:54 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161129/bdbcec50/attachment.htm From nickyperian at gmail.com Tue Nov 29 20:11:10 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Tue, 29 Nov 2016 22:11:10 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 wrote: > On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161129/e97d0ff8/attachment.htm From nat at lindenlab.com Tue Nov 29 20:30:12 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Tue, 29 Nov 2016 23:30:12 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: On Nov 29, 2016 11:11 PM, "Nicky Perian" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161129/d0f5dd2b/attachment.htm From nickyperian at gmail.com Wed Nov 30 05:53:51 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 30 Nov 2016 07:53:51 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 wrote: > On Nov 29, 2016 11:11 PM, "Nicky Perian" 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161130/19450280/attachment.htm From callum at lindenlab.com Wed Nov 30 13:04:32 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Wed, 30 Nov 2016 13:04:32 -0800 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 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 wrote: > >> On Nov 29, 2016 11:11 PM, "Nicky Perian" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161130/d4d5ae47/attachment.htm From nat at lindenlab.com Wed Nov 30 13:11:05 2016 From: nat at lindenlab.com (Nat Goodspeed) Date: Wed, 30 Nov 2016 16:11:05 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: On Wed, Nov 30, 2016 at 4:04 PM, Callum Prentice (Callum) < callum at lindenlab.com> wrote: 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. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161130/e70a7b61/attachment.htm From nickyperian at gmail.com Wed Nov 30 13:48:26 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 30 Nov 2016 15:48:26 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: >> 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) < callum at 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 > 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 >> wrote: >> >>> On Nov 29, 2016 11:11 PM, "Nicky Perian" 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161130/44c43ea6/attachment.htm From nickyperian at gmail.com Wed Nov 30 13:52:55 2016 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 30 Nov 2016 15:52:55 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <8b7e7110-ba61-2177-14e3-0424d1470ff2@lindenlab.com> Message-ID: 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 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) < > callum at 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 >> 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 >>> wrote: >>> >>>> On Nov 29, 2016 11:11 PM, "Nicky Perian" 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161130/cdbcf9e2/attachment-0001.htm From monty at lindenlab.com Wed Nov 30 15:12:35 2016 From: monty at lindenlab.com (Monty Brandenberg) Date: Wed, 30 Nov 2016 18:12:35 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: Message-ID: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> 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! From callum at lindenlab.com Wed Nov 30 16:55:31 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Wed, 30 Nov 2016 16:55:31 -0800 Subject: [opensource-dev] Windows 64 bit build issue Message-ID: I'm working with Nat Linden on the 64 bit viewer build and we've been encountering an odd error - A number of projects in 64 bit only configurations have an entry for "Force Includes" files set to XED:NO. Nothing on Google so we were stumped for a while but eventually tracked it down to a number of lines in CMakeLists.txt files of the form: *add_definitions(/FIXED:NO)*. Evidently, */FI* is the compiler command to include a forced header file - hence the *XED:NO* entry. You can see one here: https://bitbucket.org/lindenlab/viewer64/src/3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 The *FIXED* command is evidently for the linker and not the compiler but I'm not sure (a) if it's needed or (b) if it is, how to direct it at the right place. Has anyone else encountered this and already and figured it out? -- ?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/20161130/b1374390/attachment.htm From cinder at alchemyviewer.org Wed Nov 30 17:16:08 2016 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 1 Dec 2016 01:16:08 +0000 Subject: [opensource-dev] Windows 64 bit build issue In-Reply-To: References: Message-ID: <01000158b7f3f540-5f43ed87-3161-459d-8224-f817f010444f-000000@email.amazonses.com> It?s not needed. We dropped it in Alchemy when adding 64-bit support, and it continues to run fine. /FIXED:NO just ensures that code can be position independent. Maybe at some point this was needed a long time ago for apr hijinks or Windows98 compatibility or something of that nature, but you can safely remove it. --? Cinder Roxley Sent with Airmail On November 30, 2016 at 6:55:37 PM, Callum Prentice (Callum) (callum at lindenlab.com ) wrote: I'm working with Nat Linden on the 64 bit viewer build and we've been encountering an odd error - A number of projects in 64 bit only configurations have an entry for "Force Includes" files set to XED:NO.? Nothing on Google so we were stumped for a while but eventually tracked it down to a number of lines in CMakeLists.txt files of the form:?add_definitions(/FIXED:NO). Evidently, /FI is the compiler command to include a forced header file - hence the XED:NO entry. You can see one here:?https://bitbucket.org/lindenlab/viewer64/src/3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 The FIXED?command is evidently for the linker and not the compiler but I'm not sure (a) if it's needed or (b) if it is, how to direct it at the right place. Has anyone else encountered this and already and figured it out? -- ?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/20161201/0ee5cff1/attachment.htm From callum at lindenlab.com Wed Nov 30 17:36:19 2016 From: callum at lindenlab.com (Callum Linden) Date: Wed, 30 Nov 2016 17:36:19 -0800 Subject: [opensource-dev] Windows 64 bit build issue In-Reply-To: <01000158b7f3f540-5f43ed87-3161-459d-8224-f817f010444f-000000@email.amazonses.com> References: <01000158b7f3f540-5f43ed87-3161-459d-8224-f817f010444f-000000@email.amazonses.com> Message-ID: <66AE7B4C-82C8-49BE-AB74-825DFA9A9887@lindenlab.com> Thanks so much for the speedy reply Cinder. I hoped that was the case and the build seems okay without it. The other perplexing one is for the winmm_shim project. For 64 bit builds it fails with a bunch of unresolved externals which look to be related to MMX intrinsic maybe. Not at my computer right now and haven't really started to investigate but if that rings s bell after your work, please do let me know. Cheers! > On Nov 30, 2016, at 5:16 PM, Cinder Roxley wrote: > > It?s not needed. We dropped it in Alchemy when adding 64-bit support, and it continues to run fine. /FIXED:NO just ensures that code can be position independent. Maybe at some point this was needed a long time ago for apr hijinks or Windows98 compatibility or something of that nature, but you can safely remove it. > > -- > Cinder Roxley > Sent with Airmail > >> On November 30, 2016 at 6:55:37 PM, Callum Prentice (Callum) (callum at lindenlab.com) wrote: >> >> I'm working with Nat Linden on the 64 bit viewer build and we've been encountering an odd error - A number of projects in 64 bit only configurations have an entry for "Force Includes" files set to XED:NO. Nothing on Google so we were stumped for a while but eventually tracked it down to a number of lines in CMakeLists.txt files of the form: add_definitions(/FIXED:NO). Evidently, /FI is the compiler command to include a forced header file - hence the XED:NO entry. You can see one here: https://bitbucket.org/lindenlab/viewer64/src/3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 >> >> The FIXED command is evidently for the linker and not the compiler but I'm not sure (a) if it's needed or (b) if it is, how to direct it at the right place. >> >> Has anyone else encountered this and already and figured it out? >> >> -- >> ?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/20161130/aecdd3a6/attachment-0001.htm From cinder at alchemyviewer.org Wed Nov 30 18:30:22 2016 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 1 Dec 2016 02:30:22 +0000 Subject: [opensource-dev] Windows 64 bit build issue In-Reply-To: <66AE7B4C-82C8-49BE-AB74-825DFA9A9887@lindenlab.com> References: Message-ID: <01000158b837ea97-fca015fd-f886-4d22-8b0b-78650ce8204c-000000@email.amazonses.com> We nuked that whole project and set volume directly on Windows using waveOutSetVolume(HWAVEOUT, DWORD). https://bitbucket.org/alchemyviewer/alchemy/commits/b3e54a075de4440390bb1be8c9f73bfd94053a01 The shim is only needed up to XP and is completely unnecessary with the availability of WASAPI in Vista and above. --? Cinder Roxley Sent with Airmail On November 30, 2016 at 7:36:24 PM, Callum Linden (callum at lindenlab.com ) wrote: Thanks so much for the speedy reply Cinder. I hoped that was the case and the build seems okay without it.? The other perplexing one is for the winmm_shim project. For 64 bit builds it fails with a bunch of unresolved externals which look to be related to MMX intrinsic maybe. Not at my computer right now and haven't really started to investigate but if that rings s bell after your work, please do let me know.? Cheers!? On Nov 30, 2016, at 5:16 PM, Cinder Roxley > wrote: It?s not needed. We dropped it in Alchemy when adding 64-bit support, and it continues to run fine. /FIXED:NO just ensures that code can be position independent. Maybe at some point this was needed a long time ago for apr hijinks or Windows98 compatibility or something of that nature, but you can safely remove it. --? Cinder Roxley Sent with Airmail On November 30, 2016 at 6:55:37 PM, Callum Prentice (Callum) (callum at lindenlab.com ) wrote: I'm working with Nat Linden on the 64 bit viewer build and we've been encountering an odd error - A number of projects in 64 bit only configurations have an entry for "Force Includes" files set to XED:NO.? Nothing on Google so we were stumped for a while but eventually tracked it down to a number of lines in CMakeLists.txt files of the form:?add_definitions(/FIXED:NO). Evidently, /FI is the compiler command to include a forced header file - hence the XED:NO entry. You can see one here:?https://bitbucket.org/lindenlab/viewer64/src/3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 The FIXED?command is evidently for the linker and not the compiler but I'm not sure (a) if it's needed or (b) if it is, how to direct it at the right place. Has anyone else encountered this and already and figured it out? -- ?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/20161201/97559a82/attachment.htm From callum at lindenlab.com Wed Nov 30 18:55:13 2016 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Wed, 30 Nov 2016 18:55:13 -0800 Subject: [opensource-dev] Windows 64 bit build issue In-Reply-To: <01000158b837ea97-fca015fd-f886-4d22-8b0b-78650ce8204c-000000@email.amazonses.com> References: <66AE7B4C-82C8-49BE-AB74-825DFA9A9887@lindenlab.com> <01000158b837ea97-fca015fd-f886-4d22-8b0b-78650ce8204c-000000@email.amazonses.com> Message-ID: Great. I had an idea that was the case. Thanks again Cinder. On Wed, Nov 30, 2016 at 6:30 PM, Cinder Roxley wrote: > We nuked that whole project and set volume directly on Windows using > waveOutSetVolume(HWAVEOUT, DWORD). > https://bitbucket.org/alchemyviewer/alchemy/commits/ > b3e54a075de4440390bb1be8c9f73bfd94053a01 > > The shim is only needed up to XP and is completely unnecessary with the > availability of WASAPI in Vista and above. > > -- > Cinder Roxley > Sent with Airmail > > On November 30, 2016 at 7:36:24 PM, Callum Linden (callum at lindenlab.com) > wrote: > > Thanks so much for the speedy reply Cinder. I hoped that was the case and > the build seems okay without it. > > The other perplexing one is for the winmm_shim project. For 64 bit builds > it fails with a bunch of unresolved externals which look to be related to > MMX intrinsic maybe. Not at my computer right now and haven't really > started to investigate but if that rings s bell after your work, please do > let me know. > > Cheers! > > On Nov 30, 2016, at 5:16 PM, Cinder Roxley > wrote: > > It?s not needed. We dropped it in Alchemy when adding 64-bit support, and > it continues to run fine. /FIXED:NO just ensures that code can be position > independent. Maybe at some point this was needed a long time ago for apr > hijinks or Windows98 compatibility or something of that nature, but you can > safely remove it. > > -- > Cinder Roxley > Sent with Airmail > > On November 30, 2016 at 6:55:37 PM, Callum Prentice (Callum) ( > callum at lindenlab.com) wrote: > > I'm working with Nat Linden on the 64 bit viewer build and we've been > encountering an odd error - A number of projects in 64 bit only > configurations have an entry for "Force Includes" files set to XED:NO. > Nothing on Google so we were stumped for a while but eventually tracked it > down to a number of lines in CMakeLists.txt files of the form: > *add_definitions(/FIXED:NO)*. Evidently, */FI* is the compiler command to > include a forced header file - hence the *XED:NO* entry. You can see one > here: https://bitbucket.org/lindenlab/viewer64/src/ > 3f7ba2a06e5cea596e3a4006d57e3fbc4703d90f/indra/llcommon/ > CMakeLists.txt?at=default&fileviewer=file-view-default#CMakeLists.txt-248 > > The *FIXED* command is evidently for the linker and not the compiler but > I'm not sure (a) if it's needed or (b) if it is, how to direct it at the > right place. > > Has anyone else encountered this and already and figured it out? > > -- > > ?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 > > -- 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/20161130/cf1c9e00/attachment.htm