From Lance.Corrimal at eregion.de Wed Jan 4 00:25:07 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 09:25:07 +0100 Subject: [opensource-dev] windows build issues Message-ID: Hi, I am in the process of rebuilding my windows build environment... [obvious steps removed] ... and what I get from autobuild configure is: CMake Error at cmake/Prebuilt.cmake:58 (message): Failed to download or unpack prebuilt 'ogg_vorbis'. Process returned %1 ist keine zul?ssige Win32-Anwendung. Call Stack (most recent call first): cmake/Audio.cmake:11 (use_prebuilt_binary) cmake/LLAudio.cmake:3 (include) llaudio/CMakeLists.txt:6 (include) looks to me as if i'm missing something, but what? From nickyperian at gmail.com Wed Jan 4 04:23:32 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 06:23:32 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: References: Message-ID: autobuild --version s/b 1.0 unless your on the viewer64 repo. On Wed, Jan 4, 2017 at 2:25 AM, Lance Corrimal wrote: > Hi, > > I am in the process of rebuilding my windows build environment... > > [obvious steps removed] > > ... and what I get from autobuild configure is: > > > CMake Error at cmake/Prebuilt.cmake:58 (message): > Failed to download or unpack prebuilt 'ogg_vorbis'. Process returned %1 > ist keine zul?ssige Win32-Anwendung. > Call Stack (most recent call first): > cmake/Audio.cmake:11 (use_prebuilt_binary) > cmake/LLAudio.cmake:3 (include) > llaudio/CMakeLists.txt:6 (include) > > > looks to me as if i'm missing something, but what? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/d2a725d0/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 04:46:27 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 04 Jan 2017 13:46:27 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: Message-ID: <1493017.b5PeJOXzSN@kumiko> 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... From Lance.Corrimal at eregion.de Wed Jan 4 05:15:17 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 14:15:17 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: <1493017.b5PeJOXzSN@kumiko> References: <1493017.b5PeJOXzSN@kumiko> Message-ID: <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version autobuild 1.0 d:\Users\lemmy\Build\autobuild-1.0>which autobuild /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild d:\Users\lemmy\Build\autobuild-1.0>hg sum Vorg?nger: 728:7c36cb02fc10 tip Search two directories up for package_override, we need this during the VS build steps. Zweig: default ?bernehme: (clean) Aktualisiere: (aktuell) d:\Users\lemmy\Build\autobuild-1.0>hg in Vergleiche mit ssh://hg at bitbucket.org/NickyP/fs-autobuild-1.0 Suche nach ?nderungen Keine ?nderungen gefunden Am 04.01.2017 um 13:46 schrieb Lance Corrimal: > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian: >> autobuild --version >> >> s/b 1.0 unless your on the viewer64 repo. >> > 64bit here.. using your autobuild, which used to work just fine before I > reinstalled my PC... > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From oz at lindenlab.com Wed Jan 4 06:01:30 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 4 Jan 2017 09:01:30 -0500 Subject: [opensource-dev] windows build issues In-Reply-To: <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: 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. -- 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/20170104/65206275/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 06:12:31 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 15:12:31 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> 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. > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/39c22b48/attachment.htm From nickyperian at gmail.com Wed Jan 4 07:06:03 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 09:06:03 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: 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/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default&fileviewer=file-view-default#README-263 That is my dev setup and I was able to build a local FS with that setup. But, I had already edited up to autobuild-1.1. That is only used in one place at this line. https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default&fileviewer=file-view-default#README-410 Change autobuild-1.1 to autobuild-1.0 and the instruction should work. As is most often the case build instructions are a work in progress. On Wed, Jan 4, 2017 at 7:15 AM, Lance Corrimal wrote: > d:\Users\lemmy\Build\autobuild-1.0>autobuild --version > autobuild 1.0 > > > d:\Users\lemmy\Build\autobuild-1.0>which autobuild > /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild > > d:\Users\lemmy\Build\autobuild-1.0>hg sum > Vorg?nger: 728:7c36cb02fc10 tip > Search two directories up for package_override, we need this during the > VS build steps. > Zweig: default > ?bernehme: (clean) > Aktualisiere: (aktuell) > > d:\Users\lemmy\Build\autobuild-1.0>hg in > Vergleiche mit ssh://hg at bitbucket.org/NickyP/fs-autobuild-1.0 > Suche nach ?nderungen > Keine ?nderungen gefunden > > > Am 04.01.2017 um 13:46 schrieb Lance Corrimal: > > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian: > >> autobuild --version > >> > >> s/b 1.0 unless your on the viewer64 repo. > >> > > 64bit here.. using your autobuild, which used to work just fine before I > > reinstalled my PC... > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/db943eb0/attachment-0001.htm From jhwelch at gmail.com Wed Jan 4 09:04:18 2017 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 4 Jan 2017 12:04:18 -0500 Subject: [opensource-dev] post-configuration errors Message-ID: At the end of the configuration process I now am getting a screen full of these errors. Should something be adjusted to suppress them or what? -- 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. From kirstiemc555 at hotmail.co.uk Wed Jan 4 10:15:13 2017 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Wed, 4 Jan 2017 18:15:13 +0000 Subject: [opensource-dev] windows build issues In-Reply-To: <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> , <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/e1bfad77/attachment.htm From cinder at alchemyviewer.org Wed Jan 4 10:16:48 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Wed, 4 Jan 2017 18:16:48 +0000 Subject: [opensource-dev] post-configuration errors In-Reply-To: References: Message-ID: <010001596ab2a150-5d427761-6c99-463b-8492-ee05b85a5d10-000000@email.amazonses.com> It?s probably better that they be fixed. --? Cinder Roxley Sent with Airmail On January 4, 2017 at 11:04:22 AM, Jonathan Welch (jhwelch at gmail.com ) wrote: At the end of the configuration process I now am getting a screen full of these errors. Should something be adjusted to suppress them or what? -- 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. _______________________________________________ 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/20170104/78677705/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 10:20:18 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 19:20:18 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> Message-ID: <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/742305e9/attachment-0001.htm From nickyperian at gmail.com Wed Jan 4 10:58:16 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 12:58:16 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> Message-ID: cd into local repo firestorm, viewer-release are any other. From Lance.Corrimal at eregion.de Wed Jan 4 13:20:29 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 22:20:29 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> Message-ID: <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> and again: autobuild itself seems to work, at least it starts to work. it dies at the point where it tries to download the prebuild packages. here is the complete output of my problem: http://susepaste.org/33664691 Am 04.01.2017 um 19:58 schrieb Nicky Perian: > cd into local repo firestorm, viewer-release are any other. > From there enter autobuild --version an absolute path should not be > needed to reach autobuild. > It should give the version, If not, your path is not set or you may > need to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment > variable. > > > > > On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/859dd406/attachment.htm From cinder at alchemyviewer.org Wed Jan 4 13:27:22 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Wed, 4 Jan 2017 21:27:22 +0000 Subject: [opensource-dev] windows build issues In-Reply-To: <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> References: Message-ID: <010001596b6116c5-46ed7a8c-7355-45e0-ab1d-9a7be6938dc9-000000@email.amazonses.com> Looks like your python setup is fubar?d. Remove all traces of it and reinstall. pip install llbase and autobuild Do NOT use cygwin?s python and make sure that python comes earlier in your PATH than cygwin. --? Cinder Roxley Sent with Airmail On January 4, 2017 at 3:20:53 PM, Lance Corrimal (lance.corrimal at eregion.de ) wrote: and again: autobuild itself seems to work, at least it starts to work. it dies at the point where it tries to download the prebuild packages. here is the complete output of my problem: http://susepaste.org/33664691 Am 04.01.2017 um 19:58 schrieb Nicky Perian: cd into local repo ?firestorm, viewer-release are any other. From sl.nicky.ml at googlemail.com Wed Jan 4 13:27:31 2017 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Wed, 4 Jan 2017 22:27:31 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> Message-ID: You do not need -DFS_UPGRADECODES=e9d0370c-6823-4d10-986b-84e2fccf8789,bac88ff0-1a28-4fd4-aa0b-9f1e3eb8269b anymore, but this is harmless. I noticed you use: autobuild ... -- *"*...*"* Does it make a difference if you do not use " after -- and at the end of the line? I never tried to quote everything after the --, but can see how this could cause issues. On Wed, Jan 4, 2017 at 10:20 PM, Lance Corrimal wrote: > and again: autobuild itself seems to work, at least it starts to work. it > dies at the point where it tries to download the prebuild packages. > here is the complete output of my problem: > > http://susepaste.org/33664691 > > > > > > Am 04.01.2017 um 19:58 schrieb Nicky Perian: > > cd into local repo firestorm, viewer-release are any other. > From there enter autobuild --version an absolute path should not be > needed to reach autobuild. > It should give the version, If not, your path is not set or you may need > to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment variable. > > > > > On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal > 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/lindenl >> ab/autobuild-1.1). All this will be updated on the wiki once this >> project has reached the Release Candidate stage. >> lindenlab / autobuild-1.1 >> 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/wik >> i/OpenSource-Dev Please read the policies before posting to keep >> unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/80b90649/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 14:13:13 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 23:13:13 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: <010001596b6116c5-46ed7a8c-7355-45e0-ab1d-9a7be6938dc9-000000@email.amazonses.com> References: <010001596b6116c5-46ed7a8c-7355-45e0-ab1d-9a7be6938dc9-000000@email.amazonses.com> Message-ID: ...still the same.... Am 04.01.2017 um 22:27 schrieb Cinder Roxley: > Looks like your python setup is fubar?d. Remove all traces of it and > reinstall. pip install llbase and autobuild Do NOT use cygwin?s python > and make sure that python comes earlier in your PATH than cygwin. > > -- > Cinder Roxley > Sent with Airmail > > On January 4, 2017 at 3:20:53 PM, Lance Corrimal > (lance.corrimal at eregion.de ) wrote: > >> and again: autobuild itself seems to work, at least it starts to >> work. it dies at the point where it tries to download the prebuild >> packages. >> >> here is the complete output of my problem: >> >> http://susepaste.org/33664691 >> >> >> >> >> Am 04.01.2017 um 19:58 schrieb Nicky Perian: >>> cd into local repo firestorm, viewer-release are any other. >>> From there enter autobuild --version an absolute path should not be >>> needed to reach autobuild. >>> It should give the version, If not, your path is not set or you may >>> need to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment >>> variable. >>> >>> >>> >>> >>> On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal >>> > 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 >>> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/6456e576/attachment-0001.htm From Lance.Corrimal at eregion.de Wed Jan 4 14:45:18 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 4 Jan 2017 23:45:18 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: <010001596b6116c5-46ed7a8c-7355-45e0-ab1d-9a7be6938dc9-000000@email.amazonses.com> Message-ID: <5d6c0bd2-d7a4-8946-23cd-4815dfdc2f47@eregion.de> BINGO! autobuild is working now. I had to actually run distribute_setup.py and setup.py inside the autobuild repo, to actually _install_ autobuild and its dependencies into c:\python27\scripts, and now that part works. Let's see about actually compiling and packaging next. Am 04.01.2017 um 23:13 schrieb Lance Corrimal: > > ...still the same.... > > > Am 04.01.2017 um 22:27 schrieb Cinder Roxley: >> Looks like your python setup is fubar?d. Remove all traces of it and >> reinstall. pip install llbase and autobuild Do NOT use cygwin?s >> python and make sure that python comes earlier in your PATH than cygwin. >> >> -- >> Cinder Roxley >> Sent with Airmail >> >> On January 4, 2017 at 3:20:53 PM, Lance Corrimal >> (lance.corrimal at eregion.de ) wrote: >> >>> and again: autobuild itself seems to work, at least it starts to >>> work. it dies at the point where it tries to download the prebuild >>> packages. >>> >>> here is the complete output of my problem: >>> >>> http://susepaste.org/33664691 >>> >>> >>> >>> >>> Am 04.01.2017 um 19:58 schrieb Nicky Perian: >>>> cd into local repo firestorm, viewer-release are any other. >>>> From there enter autobuild --version an absolute path should not >>>> be needed to reach autobuild. >>>> It should give the version, If not, your path is not set or you may >>>> need to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment >>>> variable. >>>> >>>> >>>> >>>> >>>> On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal >>>> > 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 >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/7d84f53d/attachment.htm From nickyperian at gmail.com Wed Jan 4 16:17:56 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 18:17:56 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> Message-ID: PLATFORM: 'win32' is this normal for a 64bit build? I suggest you take a step back and make sure you can do a viewer-release build. Then build firestorm 32 bit and lastly 64 bit. On Wed, Jan 4, 2017 at 3:20 PM, Lance Corrimal wrote: > and again: autobuild itself seems to work, at least it starts to work. it > dies at the point where it tries to download the prebuild packages. > here is the complete output of my problem: > > http://susepaste.org/33664691 > > > > > > Am 04.01.2017 um 19:58 schrieb Nicky Perian: > > cd into local repo firestorm, viewer-release are any other. > From there enter autobuild --version an absolute path should not be > needed to reach autobuild. > It should give the version, If not, your path is not set or you may need > to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment variable. > > > > > On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal > 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/lindenl >> ab/autobuild-1.1). All this will be updated on the wiki once this >> project has reached the Release Candidate stage. >> lindenlab / autobuild-1.1 >> 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/wik >> i/OpenSource-Dev Please read the policies before posting to keep >> unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/a1d87f62/attachment-0001.htm From nickyperian at gmail.com Wed Jan 4 16:43:14 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 18:43:14 -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'll make the CMake logic die with an error if it doesn't see the >LL_BUILD environment variable. That will at least be less obscure than >"unexpected type 'S'", and may help identify the problem you're >encountering. I'm back. Still with this hiccup. Nicky On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed wrote: > 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! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/4705fdcc/attachment.htm From nickyperian at gmail.com Wed Jan 4 20:50:57 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 4 Jan 2017 22:50:57 -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: Backed out changeset: 54c80e27a54f restore build switches Building now. Did notice other avatars are grey. Mine looks fine. On Wed, Jan 4, 2017 at 6:43 PM, Nicky Perian wrote: > >I'll make the CMake logic die with an error if it doesn't see the > >LL_BUILD environment variable. That will at least be less obscure than > >"unexpected type 'S'", and may help identify the problem you're > >encountering. > > I'm back. Still with this hiccup. > > Nicky > > On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed wrote: > >> On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian >> wrote: >> >> > AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-vari >> ables\variables >> > has been set system wide. >> > Within my configure script (a windows batch file) is autobuild >> > source_environment and >> > autobuild configure.... >> > >> > I configure then open vs2013 and the errors continue as before. >> >> I'll make the CMake logic die with an error if it doesn't see the >> LL_BUILD environment variable. That will at least be less obscure than >> "unexpected type 'S'", and may help identify the problem you're >> encountering. >> >> > Merry Christmas!! >> >> You too! And to all a good night! >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170104/89d13819/attachment.htm From Lance.Corrimal at eregion.de Wed Jan 4 23:45:34 2017 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 5 Jan 2017 08:45:34 +0100 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: 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/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default&fileviewer=file-view-default#README-263 > > That is my dev setup and I was able to build a local FS with that > setup. But, I had already edited up to autobuild-1.1. That is only > used in one place at this line. > https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848484a49a61d82811f20a3c/README?at=default&fileviewer=file-view-default#README-410 > > Change autobuild-1.1 to autobuild-1.0 and the instruction should work. > > As is most often the case build instructions are a work in progress. > > > On Wed, Jan 4, 2017 at 7:15 AM, Lance Corrimal > > wrote: > > d:\Users\lemmy\Build\autobuild-1.0>autobuild --version > autobuild 1.0 > > > d:\Users\lemmy\Build\autobuild-1.0>which autobuild > /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild > > d:\Users\lemmy\Build\autobuild-1.0>hg sum > Vorg?nger: 728:7c36cb02fc10 tip > Search two directories up for package_override, we need this > during the > VS build steps. > Zweig: default > ?bernehme: (clean) > Aktualisiere: (aktuell) > > d:\Users\lemmy\Build\autobuild-1.0>hg in > Vergleiche mit ssh://hg at bitbucket.org/NickyP/fs-autobuild-1.0 > > Suche nach ?nderungen > Keine ?nderungen gefunden > > > Am 04.01.2017 um 13:46 schrieb Lance Corrimal: > > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian: > >> autobuild --version > >> > >> s/b 1.0 unless your on the viewer64 repo. > >> > > 64bit here.. using your autobuild, which used to work just fine > before I > > reinstalled my PC... > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > > Please read the policies before posting to keep unmoderated > posting privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/1bd47aed/attachment.htm From nickyperian at gmail.com Thu Jan 5 03:59:32 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 5 Jan 2017 05:59:32 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: Nope. Only 32. From nickyperian at gmail.com Thu Jan 5 06:47:27 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 5 Jan 2017 08:47:27 -0600 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> Message-ID: This hint for setting up python virtual environments came from Nat Linden. I used this procedure. http://timmyreilly.azurewebsites.net/python-pip-virtualenv-installation-on-windows/ As of now I have 3 environments: autobuild-1.0 pip install hg+http://bitbucket.org/lindenlab/autobuild-1.0#egg=autobuild autobuild-1.1 pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild FS pip install hg+http://bitbucket.org/NickyD/autobuild-1.0#egg=autobuild As shown above for each you will need its specific autobuild. Then, for example, use "workon FS" to set use of FS autobuild and follow FS build instructions. Just now tried FS -m64 configure and it is complaining about boost being overwriting something that is already present even though configuring from scratch. On Thu, Jan 5, 2017 at 5:59 AM, Nicky Perian wrote: > Nope. > Only 32. > > From README_BUILD_FIRESTORM_WIN64.txt > > 1.1 Visual Studio 2013 Community Edition or better with installed 64 bit > compiler. > 1.2 Or Visual Studio Express and 'Microsoft Windows SDK for Windows 7 and > .NET Framework 4'. Make sure to install at least the header and compiler > with all the latest service packs. > 2. autobuild from *https://bitbucket.org/NickyD/autobuild-1.0 > * > 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/li >> ndenlab/autobuild-1.0 >> >> https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848 >> 484a49a61d82811f20a3c/README?at=default&fileviewer=file- >> view-default#README-263 >> >> That is my dev setup and I was able to build a local FS with that setup. >> But, I had already edited up to autobuild-1.1. That is only used in one >> place at this line. >> https://bitbucket.org/kokua/kokua-sl/src/79c54527c3963bce848 >> 484a49a61d82811f20a3c/README?at=default&fileviewer=file- >> view-default#README-410 >> >> Change autobuild-1.1 to autobuild-1.0 and the instruction should work. >> >> As is most often the case build instructions are a work in progress. >> >> >> On Wed, Jan 4, 2017 at 7:15 AM, Lance Corrimal > > wrote: >> >>> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version >>> autobuild 1.0 >>> >>> >>> d:\Users\lemmy\Build\autobuild-1.0>which autobuild >>> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild >>> >>> d:\Users\lemmy\Build\autobuild-1.0>hg sum >>> Vorg?nger: 728:7c36cb02fc10 tip >>> Search two directories up for package_override, we need this during the >>> VS build steps. >>> Zweig: default >>> ?bernehme: (clean) >>> Aktualisiere: (aktuell) >>> >>> d:\Users\lemmy\Build\autobuild-1.0>hg in >>> Vergleiche mit ssh://hg at bitbucket.org/NickyP/fs-autobuild-1.0 >>> Suche nach ?nderungen >>> Keine ?nderungen gefunden >>> >>> >>> Am 04.01.2017 um 13:46 schrieb Lance Corrimal: >>> > Am Mittwoch, 4. Januar 2017, 06:23:32 CET schrieb Nicky Perian: >>> >> autobuild --version >>> >> >>> >> s/b 1.0 unless your on the viewer64 repo. >>> >> >>> > 64bit here.. using your autobuild, which used to work just fine before >>> I >>> > reinstalled my PC... >>> > >>> > _______________________________________________ >>> > Policies and (un)subscribe information available here: >>> > http://wiki.secondlife.com/wiki/OpenSource-Dev >>> > Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/e994c77f/attachment.htm From nat at lindenlab.com Thu Jan 5 11:16:45 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 5 Jan 2017 14:16:45 -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 Wed, Jan 4, 2017 at 7:43 PM, Nicky Perian wrote: >I'll make the CMake logic die with an error if it doesn't see the > >LL_BUILD environment variable. That will at least be less obscure than > >"unexpected type 'S'", and may help identify the problem you're > >encountering. > > I'm back. Still with this hiccup. > I assert that when LL_BUILD is set during 'autobuild configure', that is, at the time CMake is run, and when that LL_BUILD value contains at least "-DLL_WINDOWS=1" (as in https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default&fileviewer=file-view-default#variables-26), the "unexpected type 'S'" problem goes away. We observed that problem ourselves, and that fixed it for us. Moreover, when AUTOBUILD_VARIABLES_FILE is set to the pathname of a local clone of the above-linked file at the time you run 'autobuild source_environment', the output of 'autobuild source_environment' does contain a command to set LL_BUILD appropriately. I do not have enough information to know where in your build environment the disconnect lies. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/93de8eab/attachment.htm From nickyperian at gmail.com Thu Jan 5 13:41:39 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 5 Jan 2017 15:41:39 -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 do not have enough information to know where in your build environment the disconnect lies. autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log autobuild --address-size=64 configure -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1 |c:\cygwin64\bin\tee -a configRel.log autobuild --verbose --address-size=64 build -c ReleaseOS --no-configure 2>&1 |c:\cygwin64\bin\tee BuildRel.log Environment after running autobuild source_environment (autobuild-1.1) C:\Users\Bill\P64\viewer64>env !::=::\ !C:=C:\Users\Bill\P64\viewer64 !ExitCode=00000000 ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\Bill\AppData\Roaming asl.log=Destination=file AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables COMMONPROGRAMFILES=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=BILLAW COMSPEC=C:\WINDOWS\system32\cmd.exe DXSDK_DIR=C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\ FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer FPS_BROWSER_USER_PROFILE_STRING=Default FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Users\Bill KDS_LANGUAGE=13 LOCALAPPDATA=C:\Users\Bill\AppData\Local LOGONSERVER=\\BILLAW NUMBER_OF_PROCESSORS=8 OneDrive=C:\Users\Bill\OneDrive OS=Windows_NT PATH=/cygdrive/c/Users/Bill/Envs/autobuild-1.1/Scripts:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files (x86)/Intel/iCLS Client:/cygdrive/c/Program Files/Intel/iCLS Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/cygdrive/c/Program Files/TortoiseHg:/cygdrive/c/Python27:/cygdrive/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit:/cygdrive/c/Program Files/Microsoft SQL Server/110/Tools/Binn:/cygdrive/c/Program Files (x86)/Microsoft SDKs/TypeScript/1.0:/cygdrive/c/Program Files/Microsoft SQL Server/120/Tools/Binn:/cygdrive/c/Program Files (x86)/CMake/bin:/cygdrive/c/Python27/Scripts:/usr/bin:/usr/sbin:/cygdrive/c/Program Files (x86)/QuickTime/QTSystem:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/doxygen/bin:/cygdrive/c/Program Files (x86)/Midnight Commander:/cygdrive/c/Users/Bill/AppData/Local/Microsoft/WindowsApps PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=3c03 ProgramData=C:\ProgramData PROGRAMFILES=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=(autobuild-1.1) $P$G PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public SESSIONNAME=Console SYSTEMDRIVE=C: SYSTEMROOT=C:\WINDOWS TEMP=/cygdrive/c/Users/Bill/AppData/Local/Temp TMP=/cygdrive/c/Users/Bill/AppData/Local/Temp USERDOMAIN=BILLAW USERDOMAIN_ROAMINGPROFILE=BILLAW USERNAME=Bill USERPROFILE=C:\Users\Bill VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\ VENV=autobuild-1.1 VIRTUALENVWRAPPER_PROJECT_FILENAME=.project VIRTUAL_ENV=C:\Users\Bill\Envs\autobuild-1.1 VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\ VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\ WINDIR=C:\WINDOWS WORKON_HOME=C:\Users\Bill\Envs _OLD_VIRTUAL_PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\TortoiseHg;C:\Python27;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\CMake\bin;C:\Python27\Scripts;C:\cygwin64\bin;C:\cygwin64\usr\sbin;C:\Program Files (x86)\QuickTime\QTSystem\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseGit\bin;C:\Program Files\doxygen\bin;C:\Program Files (x86)\Midnight Commander;C:\Users\Bill\AppData\Local\Microsoft\WindowsApps; _OLD_VIRTUAL_PROMPT=$P$G TERM=cygwin HOME=/home/Bill (autobuild-1.1) C:\Users\Bill\P64\viewer64> On Thu, Jan 5, 2017 at 1:16 PM, Nat Goodspeed wrote: > On Wed, Jan 4, 2017 at 7:43 PM, Nicky Perian > wrote: > > >I'll make the CMake logic die with an error if it doesn't see the >> >LL_BUILD environment variable. That will at least be less obscure than >> >"unexpected type 'S'", and may help identify the problem you're >> >encountering. >> >> I'm back. Still with this hiccup. >> > > I assert that when LL_BUILD is set during 'autobuild configure', that is, > at the time CMake is run, and when that LL_BUILD value contains at least > "-DLL_WINDOWS=1" (as in https://bitbucket.org/lindenlab/viewer-build- > variables/src/tip/variables?at=default&fileviewer=file- > view-default#variables-26), the "unexpected type 'S'" problem goes away. > We observed that problem ourselves, and that fixed it for us. > > Moreover, when AUTOBUILD_VARIABLES_FILE is set to the pathname of a local > clone of the above-linked file at the time you run 'autobuild > source_environment', the output of 'autobuild source_environment' does > contain a command to set LL_BUILD appropriately. > > I do not have enough information to know where in your build environment > the disconnect lies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/1e6581dd/attachment.htm From nat at lindenlab.com Thu Jan 5 14:29:07 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Thu, 5 Jan 2017 17:29:07 -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, Jan 5, 2017 at 4:41 PM, Nicky Perian wrote: >>I do not have enough information to know where in your build environment > the disconnect lies. > autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log > autobuild --address-size=64 configure -c ReleaseOS -- > -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF > -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1 > |c:\cygwin64\bin\tee -a configRel.log > I could be misinterpreting; you could simply be running the above commands for purposes of creating this mail message. But if this is the command sequence you actually use to configure and build, then autobuild source_environment is not affecting the running environment. autobuild source_environment does not (cannot) directly modify the parent shell's environment variables. It simply writes to its stdout a sequence of variable assignments in bash syntax to be interpreted by the parent shell. You can achieve that either by something like: eval "$(autobuild source_environment)" or something more like: varsfile="$(mktemp -t vars.XXXXXXXX)" autobuild source_environment > "$varsfile" source "$varsfile" You might consider temporarily adding a command such as: echo "LL_BUILD = '$LL_BUILD'" to ensure that the autobuild source_environment command is in fact having the desired effect. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/11c27e8a/attachment.htm From nickyperian at gmail.com Thu Jan 5 17:52:13 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 5 Jan 2017 19:52:13 -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 was expecting to build from the windows command prompt. I can go into Cygwin64 terminal and eval "$(autobuild source_environment)" appears to run, but doesn't feedback any information that it has. Then in the windows command prompt terminal a virtualenv is set to autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal the virtualenv is lost and cannot be set and autobuild1.0 fails for no address-size. From the windows command prompt eval is a cannot find this program. I find it disturbing, to say the least, that the total autobuild cannot be completed from the windows command prompt. On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed wrote: > On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian > wrote: > > >>I do not have enough information to know where in your build environment >> the disconnect lies. >> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log >> autobuild --address-size=64 configure -c ReleaseOS -- >> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF >> -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1 >> |c:\cygwin64\bin\tee -a configRel.log >> > > I could be misinterpreting; you could simply be running the above commands > for purposes of creating this mail message. But if this is the command > sequence you actually use to configure and build, then autobuild > source_environment is not affecting the running environment. > > autobuild source_environment does not (cannot) directly modify the parent > shell's environment variables. It simply writes to its stdout a sequence of > variable assignments in bash syntax to be interpreted by the parent shell. > > You can achieve that either by something like: > > eval "$(autobuild source_environment)" > > or something more like: > > varsfile="$(mktemp -t vars.XXXXXXXX)" > autobuild source_environment > "$varsfile" > source "$varsfile" > > You might consider temporarily adding a command such as: > > echo "LL_BUILD = '$LL_BUILD'" > > to ensure that the autobuild source_environment command is in fact having > the desired effect. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170105/ba024bff/attachment-0001.htm From nickyperian at gmail.com Fri Jan 6 02:37:21 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 6 Jan 2017 04:37:21 -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: >Try creating the env file and reading it. Think about how the UNIX environment works. >The CMD shell and probably even PowerShell won't see it. I'm thinking the problem is not being able to execute bash internal commands such as "eval" and "source" from a windows CMD shell. Programs such as "tee" work OK but can't reach internals. Next try is to make it work entirely from cygwin64. Just will be some long commands to reach autobuild-1.1 which will not be a problem once autobuild-1.1 is standard. Thanks On Fri, Jan 6, 2017 at 4:16 AM, Argent wrote: > Try creating the env file and reading it. Think about how the UNIX > environment works. The CMD shell and probably even PowerShell won't see it. > > On Jan 5, 2017 19:52, "Nicky Perian" wrote: > > I was expecting to build from the windows command prompt. I can go into > Cygwin64 terminal and > eval "$(autobuild source_environment)" appears to run, but doesn't > feedback any information that it has. > Then in the windows command prompt terminal a virtualenv is set to > autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal > the virtualenv is lost and cannot be set and autobuild1.0 fails for no > address-size. From the windows command prompt eval is a cannot find this > program. > > I find it disturbing, to say the least, that the total autobuild cannot be > completed from the windows command prompt. > > > > > On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed wrote: > >> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian >> wrote: >> >> >>I do not have enough information to know where in your build >>> environment the disconnect lies. >>> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log >>> autobuild --address-size=64 configure -c ReleaseOS -- >>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF >>> -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1 >>> |c:\cygwin64\bin\tee -a configRel.log >>> >> >> I could be misinterpreting; you could simply be running the above >> commands for purposes of creating this mail message. But if this is the >> command sequence you actually use to configure and build, then autobuild >> source_environment is not affecting the running environment. >> >> autobuild source_environment does not (cannot) directly modify the parent >> shell's environment variables. It simply writes to its stdout a sequence of >> variable assignments in bash syntax to be interpreted by the parent shell. >> >> You can achieve that either by something like: >> >> eval "$(autobuild source_environment)" >> >> or something more like: >> >> varsfile="$(mktemp -t vars.XXXXXXXX)" >> autobuild source_environment > "$varsfile" >> source "$varsfile" >> >> You might consider temporarily adding a command such as: >> >> echo "LL_BUILD = '$LL_BUILD'" >> >> to ensure that the autobuild source_environment command is in fact having >> the desired effect. >> > > > _______________________________________________ > 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/20170106/fd5ad52f/attachment.htm From nickyperian at gmail.com Fri Jan 6 03:52:30 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 6 Jan 2017 05:52:30 -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: test script #!/bin/bash varsfile="$(mktemp -t vars.XXXXXXXX)" autobuild source_environment > "$varsfile" source "$varsfile" echo "LL_BUILD = '$LL_BUILD'" Output Bill at BILLAW /cygdrive/c/Users/Bill/P64/viewer64 $ bash buildit.sh LL_BUILD = '' $varsfile contents export AUTOBUILD='C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild' export AUTOBUILD_WIN_VSPLATFORM='Win32' export AUTOBUILD_CONFIGURE_ARCH='i386' export AUTOBUILD_VERSION_STRING='1.1.0' export AUTOBUILD_WIN_CMAKE_GEN='Visual Studio 12' export AUTOBUILD_PLATFORM='windows' LL_BUILD_BASE_MACROS='/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_LINUX_RELWITHDEBINFO='-O0 -g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_BASE='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_WINDOWS_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_LINUX_RELEASE='-O2 -g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_LINUX_DEBUG_SWITCHES='-O0 -g -fPIC' LL_BUILD_LINUX_RELWITHDEBINFO_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_DARWIN_RELEASE_SWITCHES='-O3 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/' LL_BUILD_POSIX_BASE_MACROS='-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_LINUX_BASE='-g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_RELEASE_MACROS='/DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_WINDOWS_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_DARWIN_BASE_MACROS='-DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_RELEASE_MACROS='-DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DNDEBUG -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_LINUX_RELWITHDEBINFO_SWITCHES='-O0 -g -fPIC' LL_BUILD_RELEASE_SWITCHES='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_LINUX_BASE_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_DARWIN_DEBUG_MACROS='-D_DEBUG -DLL_DEBUG=1 -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_RELWITHDEBINFO_SWITCHES='-O0 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/' LL_BUILD_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_RELEASE='-O3 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DNDEBUG -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_RELWITHDEBINFO_MACROS='/DLL_RELEASE=1 /DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_RELWITHDEBINFO='-O0 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ -DLL_RELEASE=1 -DNDEBUG -DLL_RELEASE_WITH_DEBUG_INFO=1 -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_RELEASE_SWITCHES='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_LINUX_RELEASE_SWITCHES='-O2 -g -fPIC' LL_BUILD_LINUX_RELEASE_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_BASE_SWITCHES='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_DARWIN_DEBUG_SWITCHES='-O0 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/' LL_BUILD_WINDOWS_BASE_MACROS='/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_WINDOWS_RELWITHDEBINFO='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_WINDOWS_BASE_SWITCHES='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT' LL_BUILD_LINUX_DEBUG_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_RELWITHDEBINFO_MACROS='/DLL_RELEASE=1 /DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_RELEASE='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_WINDOWS_RELEASE_MACROS='/DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_RELWITHDEBINFO='/MD /Od /Ob0 /INCREMENTAL /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RELEASE_WITH_DEBUG_INFO=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_RELWITHDEBINFO_MACROS='-DLL_RELEASE=1 -DNDEBUG -DLL_RELEASE_WITH_DEBUG_INFO=1 -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_DARWIN_BASE_SWITCHES='-fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/' LL_BUILD_LINUX_DEBUG='-O0 -g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_WINDOWS_RELEASE='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1 /DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_DARWIN_DEBUG='-O0 -fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ -D_DEBUG -DLL_DEBUG=1 -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' LL_BUILD_BASE='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1' LL_BUILD_LINUX_BASE_SWITCHES='-g -fPIC' USE_INCREDIBUILD='0' LL_BUILD_DARWIN_BASE='-fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ -DPIC -DLL_DARWIN=1 -DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1' set_build_variables() { # set_build_variables is a dead branch of the evolutionary tree. The # functionality formerly engaged by the command: # set_build_variables convenience Release # has now been subsumed into autobuild source_environment itself. But # since a number of build-cmd.sh scripts have been tweaked to call # set_build_variables, make it produce an explanatory error. While it # would be simpler to remove the shell function and produce an error # that way, that could leave a developer scrambling to figure out: # okay, this line broke, why? Did set_build_variables go away? Did its # name change? What replaces it? echo "set_build_variables is no longer needed. Pass to autobuild source_environment the pathname of your local clone of the build-variables/variables file, or set AUTOBUILD_VARIABLES_FILE to that pathname before autobuild source_environment, and remove the set_build_variables command. All the same variables will be set." 1>&2 exit 1 } # Usage: # switches="$(remove_switch -DPIC $LL_BUILD)" # It's important NOT to quote whichever compiler-arguments string you pass to # remove_switch (LL_BUILD in the example above), just as it's important not to # quote it when passing it to the compiler itself: bash must parse into # separate tokens. remove_switch() { local todel="$1" shift local out=() for sw do if [ "$sw" != "$todel" ] then # append $sw to out out[${#out[*]}]="$sw" fi done echo "${out[@]}" } # Usage: # switches="$(replace_switch -DPIC -DPOC $LL_BUILD)" # It's important NOT to quote whichever compiler-arguments string you pass to # replace_switch (LL_BUILD in the example above), just as it's important not to # quote it when passing it to the compiler itself: bash must parse into # separate tokens. replace_switch() { local todel="$1" local toins="$2" shift shift echo "$toins $(remove_switch "$todel" "$@")" } fix_dylib_id() { local dylib=$1 local dylink="$dylib" if [ -f "$dylib" ]; then if [ -L "$dylib" ]; then dylib="$(readlink "$dylib")" fi install_name_tool -id "@executable_path/../Resources/$dylib" "$dylib" if [ "$dylib" != "$dylink" ]; then ln -svf "$dylib" "$dylink" fi fi } build_sln() { local solution=$1 local config=$2 local proj="${3:-}" if (($USE_INCREDIBUILD)) ; then BuildConsole "$solution" ${proj:+/PRJ="$proj"} /CFG="$config" else devenv.com "$(cygpath -w "$solution")" /build "$config" ${proj:+/project "$proj"} fi } # function for loading visual studio related env vars load_vsvars() { export DEVENVDIR="C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE" export EXTENSIONSDKDIR="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs" export FRAMEWORK40VERSION="v4.0" export FRAMEWORKDIR="C:\Windows\Microsoft.NET\Framework" export FRAMEWORKDIR32="C:\Windows\Microsoft.NET\Framework" export FRAMEWORKVERSION="v4.0.30319" export FRAMEWORKVERSION32="v4.0.30319" export FSHARPINSTALLDIR="C:\Program Files (x86)\Microsoft SDKs\F#\3.1\Framework\v4.0" export INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;" export LIB="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86;" export LIBPATH="C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0\References\CommonConfiguration\neutral;" export PATH="/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/cygdrive/c/Program Files (x86)/Microsoft SDKs/F#/3.1/Framework/v4.0/:/cygdrive/c/Program Files (x86)/MSBuild/12.0/bin:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/Tools:/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/VCPackages:/cygdrive/c/Program Files (x86)/HTML Help Workshop:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/Team Tools/Performance Tools:/cygdrive/c/Program Files (x86)/Windows Kits/8.1/bin/x86:/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v8.1A/bin/NETFX 4.5.1 Tools/:/cygdrive/c/Users/Bill/Envs/autobuild-1.1/Scripts:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files (x86)/Intel/iCLS Client/:/cygdrive/c/Program Files/Intel/iCLS Client/:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/cygdrive/c/Program Files/TortoiseHg:/cygdrive/c/Python27:/cygdrive/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit/:/cygdrive/c/Program Files/Microsoft SQL Server/110/Tools/Binn/:/cygdrive/c/Program Files (x86)/Microsoft SDKs/TypeScript/1.0/:/cygdrive/c/Program Files/Microsoft SQL Server/120/Tools/Binn/:/cygdrive/c/Program Files (x86)/CMake/bin:/cygdrive/c/Python27/Scripts:/usr/bin:/usr/sbin:/cygdrive/c/Program Files (x86)/QuickTime/QTSystem/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/doxygen/bin:/cygdrive/c/Program Files (x86)/Midnight Commander:/cygdrive/c/Users/Bill/AppData/Local/Microsoft/WindowsApps::$PATH" export VCINSTALLDIR="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC" export VISUALSTUDIOVERSION="12.0" export VSINSTALLDIR="C:\Program Files (x86)\Microsoft Visual Studio 12.0" export WINDOWSSDKDIR="C:\Program Files (x86)\Windows Kits\8.1" export WINDOWSSDK_EXECUTABLEPATH_X64="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64" export WINDOWSSDK_EXECUTABLEPATH_X86="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools" } if ! (($USE_INCREDIBUILD)) ; then load_vsvars fi ********************************************************************* The environment has no LL_BUILD variables. On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed wrote: > On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian > wrote: > > >>I do not have enough information to know where in your build environment >> the disconnect lies. >> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log >> autobuild --address-size=64 configure -c ReleaseOS -- >> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF >> -DPACKAGE:BOOL=FALSE -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE 2>&1 >> |c:\cygwin64\bin\tee -a configRel.log >> > > I could be misinterpreting; you could simply be running the above commands > for purposes of creating this mail message. But if this is the command > sequence you actually use to configure and build, then autobuild > source_environment is not affecting the running environment. > > autobuild source_environment does not (cannot) directly modify the parent > shell's environment variables. It simply writes to its stdout a sequence of > variable assignments in bash syntax to be interpreted by the parent shell. > > You can achieve that either by something like: > > eval "$(autobuild source_environment)" > > or something more like: > > varsfile="$(mktemp -t vars.XXXXXXXX)" > autobuild source_environment > "$varsfile" > source "$varsfile" > > You might consider temporarily adding a command such as: > > echo "LL_BUILD = '$LL_BUILD'" > > to ensure that the autobuild source_environment command is in fact having > the desired effect. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170106/498e5bd7/attachment-0001.htm From nat at lindenlab.com Fri Jan 6 06:46:31 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Fri, 6 Jan 2017 09:46:31 -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, Jan 5, 2017 at 8:52 PM, Nicky Perian wrote: I was expecting to build from the windows command prompt. I can go into > Cygwin64 terminal and > eval "$(autobuild source_environment)" appears to run, but doesn't > feedback any information that it has. > Running that command performs a bunch of bash variable assignments and 'export' commands. It should result in an enriched environment, but you're right, the command itself doesn't produce output -- unless the bash switch 'set -x' (shell tracing) is in effect. > I find it disturbing, to say the least, that the total autobuild cannot be > completed from the windows command prompt. > Sigh, I'm afraid my reply was off-base. I was looking at the way you were manually executing autobuild source_environment, which could only have the effect of producing output to stdout -- in this case, to your log file. But the fact is that current autobuild 1.1's configure and build commands internally execute the equivalent of autobuild source_environment to produce the environment passed to the relevant commands specified in autobuild.xml. So *if you want the parent shell script* to see the variables produced by autobuild source_environment, you must use either the 'eval' construct or redirect source_environment output to a file and then 'source' that file, as shown in a previous message. But 'autobuild configure' and 'autobuild build' will now internally run 'autobuild source_environment' for their own processing. So if you don't need to see autobuild source_environment variables in the parent shell, you can skip explicitly running 'autobuild source_environment' altogether. Digression: https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default&fileviewer=file-view-default sets variables of the form LL_BUILD_WINDOWS_RELEASE, etc. for DARWIN and LINUX and RELWITHDEBINFO. Since autobuild source_environment knows the current platform, it also emits an abbreviated variable LL_BUILD_RELEASE with the same value as LL_BUILD_WINDOWS_RELEASE (or whichever platform). Given the configuration you want to build, it also emits another abbreviated variable LL_BUILD with the same value as LL_BUILD_RELEASE (or whichever configuration). You can see this when you run 'autobuild source_environment -c Release' with AUTOBUILD_VARIABLES_FILE set in your environment. What should happen is that autobuild configure will internally run 'autobuild source_environment' for the current platform and build configuration. Thus the CMake logic specified in the viewer's autobuild.xml, invoked by 'autobuild configure', should (!) see a non-empty LL_BUILD variable... if AUTOBUILD_VARIABLES_FILE is visible in the environment passed to autobuild configure. When the platform-and-config-appropriate LL_BUILD value (containing e.g. -DLL_WINDOWS) is passed to the viewer's CMake machinery, CMake will in turn pass those command-line switches to the compiler: https://bitbucket.org/lindenlab/viewer64/src/tip/indra/cmake/00-Common.cmake?at=default&fileviewer=file-view-default#00-Common.cmake-21 When indra/llcommon/llpreprocessor.h sees (e.g.) LL_WINDOWS, it #defines LL_TYPEOF(): https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llpreprocessor.h?fileviewer=file-view-default#llpreprocessor.h-195 And it was lack of LL_TYPEOF() that was causing those baffling "unexpected type 'S'" errors in llunittype.h: https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llunittype.h?fileviewer=file-view-default#llunittype.h-47 If you are still seeing those errors, you might try adding message output to indra/cmake/00-Common.cmake, something like: MESSAGE(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_FILE}'") MESSAGE(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_RELEASE}'") MESSAGE(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'") MESSAGE(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") Of course, if you're trying to build RelWithDebInfo instead of Release, try reporting LL_BUILD_WINDOWS_RELWITHDEBINFO and LL_BUILD_RELWITHDEBINFO instead of (or as well as) the output above. Sorry for not explaining this more fully yesterday! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170106/855aca9d/attachment.html From nickyperian at gmail.com Sat Jan 7 16:32:22 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 7 Jan 2017 18:32:22 -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: Snip Variables.cmake # Switches set here and in 00-Common.cmake must agree with # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables # Reading $LL_BUILD is an attempt to directly use those switches. #message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_FILE}'") #message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_RELEASE}'") #message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'") set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") if ("$ENV{LL_BUILD}" STREQUAL "") message(FATAL_ERROR "Environment variable LL_BUILD must be set") endif () Above allows configure to complete, but I would like a better place or better yet some autobuild involvement to set LL_BUILD based to the chosen Release, RelWithDebugInfo, Debug build. Next, Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002: ignoring unknown option '/OP' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/OT' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/O:' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/OR' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/OE' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/OF' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] cl : Command line warning D9002: ignoring unknown option '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] No idea where /O* switches are set but appear to be included in every *.vcxproj. '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO /NODEFAULTLIB:LIBCMT*" These link switches are set in 00-Common.cmake. Once removed those warning are no longer listed. This in likely a case of putting link switches in cl without a pass through. I suspect the '/O*' switches are link switches also, but grep was of no help finding where they are set. Good news is the build completed without the crazy errors encountered earlier. On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed wrote: > On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian > wrote: > > >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 > /DLL_RLEASE_FOR_DOWNLOAD=1 > >> /DNDEBUG > > > > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the > variable > > name changed? > > Thank you for pointing that out! > https://bitbucket.org/lindenlab/viewer-build-variables/commits/ > a9d6c3061349a14289cffb536320f0aa7bdf472f > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170107/746e8228/attachment.htm From nickyperian at gmail.com Mon Jan 9 17:47:51 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Mon, 9 Jan 2017 19:47:51 -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: LL list server issue so resending On Sat, Jan 7, 2017 at 10:13 PM, Nicky Perian wrote: > brute force setting of LL_BUILD environment variable. > There may be a better/smarter way, but it appears to work. > # HG changeset patch > # User Nicky Perian > # Date 1483848353 21600 > # Sat Jan 07 22:05:53 2017 -0600 > # Node ID 7b4fb3c48718213d1cd8c1e6c6dca0d50c95d78e > # Parent 390776087c1d7c83f04af629340839fadfdd0735 > Brute force set LL_BUILD based on System name and Build type. If it isn't > set error out of configure. > > diff -r 390776087c1d -r 7b4fb3c48718 indra/cmake/Variables.cmake > --- a/indra/cmake/Variables.cmake Mon Dec 19 05:11:36 2016 -0600 > +++ b/indra/cmake/Variables.cmake Sat Jan 07 22:05:53 2017 -0600 > @@ -12,10 +12,37 @@ > # Switches set here and in 00-Common.cmake must agree with > # https://bitbucket.org/lindenlab/viewer-build- > variables/src/tip/variables > # Reading $LL_BUILD is an attempt to directly use those switches. > +if (${CMAKE_SYSTEM_NAME} MATCHES "Windows") > + if (CMAKE_BUILD_TYPE MATCHES "Debug") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_DEBUG}) > + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELWITHDEBINFO}) > + elseif (CMAKE_BUILD_TYPE MATCHES "Release") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) > + endif(CMAKE_BUILD_TYPE MATCHES "Debug") > +endif(${CMAKE_SYSTEM_NAME} MATCHES "Windows") > +if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin") > + if (CMAKE_BUILD_TYPE MATCHES "Debug") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_DEBUG}) > + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELWITHDEBINFO}) > + elseif (CMAKE_BUILD_TYPE MATCHES "Release") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELEASE}) > + endif(CMAKE_BUILD_TYPE MATCHES "Debug") > +endif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin") > +if (${CMAKE_SYSTEM_NAME} MATCHES "Linux") > + if (CMAKE_BUILD_TYPE MATCHES "Debug") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_DEBUG}) > + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELWITHDEBINFO}) > + elseif (CMAKE_BUILD_TYPE MATCHES "Release") > + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELEASE}) > + endif(CMAKE_BUILD_TYPE MATCHES "Debug") > +endif(${CMAKE_SYSTEM_NAME} MATCHES "Linux") > if ("$ENV{LL_BUILD}" STREQUAL "") > message(FATAL_ERROR "Environment variable LL_BUILD must be set") > endif () > - > +#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") > # Relative and absolute paths to subtrees. > > if(NOT DEFINED ${CMAKE_CURRENT_LIST_FILE}_INCLUDED) > > > > On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian > wrote: > >> Snip Variables.cmake >> # Switches set here and in 00-Common.cmake must agree with >> # https://bitbucket.org/lindenlab/viewer-build-variables/src/ >> tip/variables >> # Reading $LL_BUILD is an attempt to directly use those switches. >> #message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_FILE >> }'") >> #message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_RELEASE >> }'") >> #message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'") >> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) >> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") >> if ("$ENV{LL_BUILD}" STREQUAL "") >> message(FATAL_ERROR "Environment variable LL_BUILD must be set") >> endif () >> >> Above allows configure to complete, but I would like a better place or >> better yet some autobuild involvement to set LL_BUILD based to the chosen >> Release, RelWithDebugInfo, Debug build. >> >> Next, >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> cl : Command line warning D9002: ignoring unknown option '/OP' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/OT' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/O:' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/OR' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/OE' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/OF' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO' >> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] >> cl : Command line warning D9002: ignoring unknown option >> '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\bu >> ild-vc120-64\llcommon\llcommon.vcxproj] >> >> No idea where /O* switches are set but appear to be included in every >> *.vcxproj. >> '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here >> LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO >> /NODEFAULTLIB:LIBCMT*" >> >> These link switches are set in 00-Common.cmake. >> >> Once removed those warning are no longer listed. This in likely a case of >> putting link switches in cl without a pass through. I suspect the '/O*' >> switches are link switches also, but grep was of no help finding where they >> are set. >> >> Good news is the build completed without the crazy errors encountered >> earlier. >> >> >> >> >> On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed wrote: >> >>> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian >>> wrote: >>> >>> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 >>> /DLL_RLEASE_FOR_DOWNLOAD=1 >>> >> /DNDEBUG >>> > >>> > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the >>> variable >>> > name changed? >>> >>> Thank you for pointing that out! >>> https://bitbucket.org/lindenlab/viewer-build-variables/commi >>> ts/a9d6c3061349a14289cffb536320f0aa7bdf472f >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170109/bd51f8b8/attachment-0001.htm From sl.nicky.ml at googlemail.com Tue Jan 10 10:30:09 2017 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Tue, 10 Jan 2017 19:30:09 +0100 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: > > set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) > #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") > if ("$ENV{LL_BUILD}" STREQUAL "") > message(FATAL_ERROR "Environment variable LL_BUILD must be set") > endif () > > Above allows configure to complete, but I would like a better place or > better yet some autobuild involvement to set LL_BUILD based to the chosen > Release, RelWithDebugInfo, Debug build. > > > Autobuild tries to do this by some machinery in source environment, but it fails because you use ReleaseOS. I did encounter the same problem just a few minutes ago with ReleaseFS and had to edit the file variables in the build-variables repository. Once I added a variable for the configuration, LL_BUILD will be set as desired. https://bitbucket.org/NickyD/viewer-build-variables/commits/cfab877696c6a35af1d80e5d17ea7acfffa6c762 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170110/ba5ff88c/attachment.htm From nat at lindenlab.com Sat Jan 7 12:17:58 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Sat, 7 Jan 2017 15:17:58 -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 Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian wrote: >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1 >> /DNDEBUG > > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the variable > name changed? Thank you for pointing that out! https://bitbucket.org/lindenlab/viewer-build-variables/commits/a9d6c3061349a14289cffb536320f0aa7bdf472f From nickyperian at gmail.com Mon Jan 9 17:49:11 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Mon, 9 Jan 2017 19:49:11 -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: LL list server problem so resending. On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian wrote: > Snip Variables.cmake > # Switches set here and in 00-Common.cmake must agree with > # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables > # Reading $LL_BUILD is an attempt to directly use those switches. > #message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_ > FILE}'") > #message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_ > RELEASE}'") > #message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'") > set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) > #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") > if ("$ENV{LL_BUILD}" STREQUAL "") > message(FATAL_ERROR "Environment variable LL_BUILD must be set") > endif () > > Above allows configure to complete, but I would like a better place or > better yet some autobuild involvement to set LL_BUILD based to the chosen > Release, RelWithDebugInfo, Debug build. > > Next, > Copyright (C) Microsoft Corporation. All rights reserved. > > cl : Command line warning D9002: ignoring unknown option '/OP' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OT' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/O:' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OR' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OE' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OF' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option > '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\ > build-vc120-64\llcommon\llcommon.vcxproj] > > No idea where /O* switches are set but appear to be included in every > *.vcxproj. > '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here > LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO > /NODEFAULTLIB:LIBCMT*" > > These link switches are set in 00-Common.cmake. > > Once removed those warning are no longer listed. This in likely a case of > putting link switches in cl without a pass through. I suspect the '/O*' > switches are link switches also, but grep was of no help finding where they > are set. > > Good news is the build completed without the crazy errors encountered > earlier. > > > > > On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed wrote: > >> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian >> wrote: >> >> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 >> /DLL_RLEASE_FOR_DOWNLOAD=1 >> >> /DNDEBUG >> > >> > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the >> variable >> > name changed? >> >> Thank you for pointing that out! >> https://bitbucket.org/lindenlab/viewer-build-variables/ >> commits/a9d6c3061349a14289cffb536320f0aa7bdf472f >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170109/e2edce84/attachment.html From nickyperian at gmail.com Sat Jan 7 20:13:27 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 7 Jan 2017 22:13:27 -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: brute force setting of LL_BUILD environment variable. There may be a better/smarter way, but it appears to work. # HG changeset patch # User Nicky Perian # Date 1483848353 21600 # Sat Jan 07 22:05:53 2017 -0600 # Node ID 7b4fb3c48718213d1cd8c1e6c6dca0d50c95d78e # Parent 390776087c1d7c83f04af629340839fadfdd0735 Brute force set LL_BUILD based on System name and Build type. If it isn't set error out of configure. diff -r 390776087c1d -r 7b4fb3c48718 indra/cmake/Variables.cmake --- a/indra/cmake/Variables.cmake Mon Dec 19 05:11:36 2016 -0600 +++ b/indra/cmake/Variables.cmake Sat Jan 07 22:05:53 2017 -0600 @@ -12,10 +12,37 @@ # Switches set here and in 00-Common.cmake must agree with # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables # Reading $LL_BUILD is an attempt to directly use those switches. +if (${CMAKE_SYSTEM_NAME} MATCHES "Windows") + if (CMAKE_BUILD_TYPE MATCHES "Debug") + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_DEBUG}) + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELWITHDEBINFO}) + elseif (CMAKE_BUILD_TYPE MATCHES "Release") + set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) + endif(CMAKE_BUILD_TYPE MATCHES "Debug") +endif(${CMAKE_SYSTEM_NAME} MATCHES "Windows") +if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin") + if (CMAKE_BUILD_TYPE MATCHES "Debug") + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_DEBUG}) + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELWITHDEBINFO}) + elseif (CMAKE_BUILD_TYPE MATCHES "Release") + set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELEASE}) + endif(CMAKE_BUILD_TYPE MATCHES "Debug") +endif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin") +if (${CMAKE_SYSTEM_NAME} MATCHES "Linux") + if (CMAKE_BUILD_TYPE MATCHES "Debug") + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_DEBUG}) + elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo") + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELWITHDEBINFO}) + elseif (CMAKE_BUILD_TYPE MATCHES "Release") + set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELEASE}) + endif(CMAKE_BUILD_TYPE MATCHES "Debug") +endif(${CMAKE_SYSTEM_NAME} MATCHES "Linux") if ("$ENV{LL_BUILD}" STREQUAL "") message(FATAL_ERROR "Environment variable LL_BUILD must be set") endif () - +#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") # Relative and absolute paths to subtrees. if(NOT DEFINED ${CMAKE_CURRENT_LIST_FILE}_INCLUDED) On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian wrote: > Snip Variables.cmake > # Switches set here and in 00-Common.cmake must agree with > # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables > # Reading $LL_BUILD is an attempt to directly use those switches. > #message(STATUS "AUTOBUILD_VARIABLES_FILE = '$ENV{AUTOBUILD_VARIABLES_ > FILE}'") > #message(STATUS "LL_BUILD_WINDOWS_RELEASE = '$ENV{LL_BUILD_WINDOWS_ > RELEASE}'") > #message(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'") > set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) > #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") > if ("$ENV{LL_BUILD}" STREQUAL "") > message(FATAL_ERROR "Environment variable LL_BUILD must be set") > endif () > > Above allows configure to complete, but I would like a better place or > better yet some autobuild involvement to set LL_BUILD based to the chosen > Release, RelWithDebugInfo, Debug build. > > Next, > Copyright (C) Microsoft Corporation. All rights reserved. > > cl : Command line warning D9002: ignoring unknown option '/OP' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OT' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/O:' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OR' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OE' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/OF' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO' > [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj] > cl : Command line warning D9002: ignoring unknown option > '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\ > build-vc120-64\llcommon\llcommon.vcxproj] > > No idea where /O* switches are set but appear to be included in every > *.vcxproj. > '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here > LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO > /NODEFAULTLIB:LIBCMT*" > > These link switches are set in 00-Common.cmake. > > Once removed those warning are no longer listed. This in likely a case of > putting link switches in cl without a pass through. I suspect the '/O*' > switches are link switches also, but grep was of no help finding where they > are set. > > Good news is the build completed without the crazy errors encountered > earlier. > > > > > On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed wrote: > >> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian >> wrote: >> >> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 >> /DLL_RLEASE_FOR_DOWNLOAD=1 >> >> /DNDEBUG >> > >> > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the >> variable >> > name changed? >> >> Thank you for pointing that out! >> https://bitbucket.org/lindenlab/viewer-build-variables/ >> commits/a9d6c3061349a14289cffb536320f0aa7bdf472f >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170107/3a766730/attachment.html From oz at lindenlab.com Thu Jan 12 08:43:00 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 12 Jan 2017 11:43:00 -0500 Subject: [opensource-dev] windows build issues In-Reply-To: References: <1493017.b5PeJOXzSN@kumiko> <29fe9669-3688-bd87-18f0-128c029c27ed@eregion.de> <3363ef6a-3362-6919-4c7c-6f94700688b9@eregion.de> <623d916b-00ec-181a-6393-5cd78d63ff57@eregion.de> <66802e76-3ae4-86c0-6d70-1d74f5324056@eregion.de> Message-ID: <1a934652-da30-12f9-8631-1e4bfb92b806@lindenlab.com> On 2017-01-04 16:27 , Nicky D. wrote: > > I noticed you use: > autobuild ... -- *"*...*"* > > Does it make a difference if you do not use " after -- and at the end > of the line? I never tried to quote everything after the --, but can > see how this could cause issues. It probably will. One of the changes we made to autobuild in 1.1 is that it used to run subcommands by concatenating all the arguments into one string and then pass that to a shell. That's not as secure or robust as just invoking the command directly, so we changed it so that there's no shell used now. -- 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/20170112/a25c14bd/attachment.htm From nickyperian at gmail.com Thu Jan 12 10:55:58 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 12 Jan 2017 12:55:58 -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: [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey world. Terrain and most prim textures are grey. Full bright textures and my avatar appear normal. Is this the same with KDU? I haven't a KDU license or I would check myself. On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. wrote: > set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) >> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") >> if ("$ENV{LL_BUILD}" STREQUAL "") >> message(FATAL_ERROR "Environment variable LL_BUILD must be set") >> endif () >> >> Above allows configure to complete, but I would like a better place or >> better yet some autobuild involvement to set LL_BUILD based to the chosen >> Release, RelWithDebugInfo, Debug build. >> >> >> > Autobuild tries to do this by some machinery in source environment, but it > fails because you use ReleaseOS. I did encounter the same problem just a > few minutes ago > with ReleaseFS and had to edit the file variables in the build-variables > repository. > Once I added a variable for the configuration, LL_BUILD will be set as > desired. > > https://bitbucket.org/NickyD/viewer-build-variables/commits/ > cfab877696c6a35af1d80e5d17ea7acfffa6c762 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170112/49f3a3a0/attachment.htm From callum at lindenlab.com Thu Jan 12 10:59:43 2017 From: callum at lindenlab.com (Callum Prentice (Callum)) Date: Thu, 12 Jan 2017 10:59:43 -0800 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: KDU build here was indistinguishable from the 32bit viewer-release on first inspection. Tried both with full cache and cleaned one. On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian wrote: > [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey > world. Terrain and most prim textures are grey. Full bright textures and > my avatar appear normal. Is this the same with KDU? I haven't a KDU license > or I would check myself. > > On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. > wrote: > >> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) >>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") >>> if ("$ENV{LL_BUILD}" STREQUAL "") >>> message(FATAL_ERROR "Environment variable LL_BUILD must be set") >>> endif () >>> >>> Above allows configure to complete, but I would like a better place or >>> better yet some autobuild involvement to set LL_BUILD based to the chosen >>> Release, RelWithDebugInfo, Debug build. >>> >>> >>> >> Autobuild tries to do this by some machinery in source environment, but >> it fails because you use ReleaseOS. I did encounter the same problem just a >> few minutes ago >> with ReleaseFS and had to edit the file variables in the build-variables >> repository. >> Once I added a variable for the configuration, LL_BUILD will be set as >> desired. >> >> https://bitbucket.org/NickyD/viewer-build-variables/commits/ >> cfab877696c6a35af1d80e5d17ea7acfffa6c762 >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- CALLUM PRENTICE | Software Engineer LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170112/5f529296/attachment.htm From nickyperian at gmail.com Fri Jan 13 14:01:05 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 13 Jan 2017 16:01:05 -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: Does "autobuild uninstall xxxxx" work for autobuild-1.1? On Thu, Jan 12, 2017 at 12:59 PM, Callum Prentice (Callum) < callum at lindenlab.com> wrote: > KDU build here was indistinguishable from the 32bit viewer-release on > first inspection. > > Tried both with full cache and cleaned one. > > On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian > wrote: > >> [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey >> world. Terrain and most prim textures are grey. Full bright textures and >> my avatar appear normal. Is this the same with KDU? I haven't a KDU license >> or I would check myself. >> >> On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. >> wrote: >> >>> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE}) >>>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'") >>>> if ("$ENV{LL_BUILD}" STREQUAL "") >>>> message(FATAL_ERROR "Environment variable LL_BUILD must be set") >>>> endif () >>>> >>>> Above allows configure to complete, but I would like a better place or >>>> better yet some autobuild involvement to set LL_BUILD based to the chosen >>>> Release, RelWithDebugInfo, Debug build. >>>> >>>> >>>> >>> Autobuild tries to do this by some machinery in source environment, but >>> it fails because you use ReleaseOS. I did encounter the same problem just a >>> few minutes ago >>> with ReleaseFS and had to edit the file variables in the build-variables >>> repository. >>> Once I added a variable for the configuration, LL_BUILD will be set as >>> desired. >>> >>> https://bitbucket.org/NickyD/viewer-build-variables/commits/ >>> cfab877696c6a35af1d80e5d17ea7acfffa6c762 >>> >>> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > -- > > CALLUM PRENTICE | Software Engineer > > LINDEN LAB | Create Virtual Experiences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/69b15238/attachment.htm From oz at lindenlab.com Fri Jan 13 14:04:57 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 13 Jan 2017 17:04:57 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: Message-ID: <77d6b94f-45dd-9942-52a4-b0f74b608869@lindenlab.com> On 2017-01-13 17:01 , Nicky Perian wrote: > Does "autobuild uninstall xxxxx" work for autobuild-1.1? > as far as we know, yes Documentation that it doesn't is of course welcome -- OZ LINDEN | Engineering Director, Second Life email or hangouts: 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/20170113/d5744797/attachment.htm From nickyperian at gmail.com Fri Jan 13 14:08:01 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 13 Jan 2017 16:08:01 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: <77d6b94f-45dd-9942-52a4-b0f74b608869@lindenlab.com> References: <77d6b94f-45dd-9942-52a4-b0f74b608869@lindenlab.com> Message-ID: >>Documentation that it doesn't is of course welcome (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall openjpeg Traceback (most recent call last): File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line 11, in load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 263, in main sys.exit(Autobuild().main(sys.argv[1:])) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 250, in main tool_to_run.run(args) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 151, in run uninstall_packages(args, installed_filename, args.package, args.dry_run) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages installed_file.save() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", line 366, in save file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation)) IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' On Fri, Jan 13, 2017 at 4:04 PM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2017-01-13 17:01 , Nicky Perian wrote: > > Does "autobuild uninstall xxxxx" work for autobuild-1.1? > > as far as we know, yes > > Documentation that it doesn't is of course welcome > > > -- > OZ LINDEN | Engineering Director, Second Life > email or hangouts: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/479ecfd7/attachment.htm From nickyperian at gmail.com Fri Jan 13 14:24:30 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 13 Jan 2017 16:24:30 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <77d6b94f-45dd-9942-52a4-b0f74b608869@lindenlab.com> Message-ID: more... (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size=32 uninstall openjpeg Traceback (most recent call last): File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line 11, in load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 263, in main sys.exit(Autobuild().main(sys.argv[1:])) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 250, in main tool_to_run.run(args) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 151, in run uninstall_packages(args, installed_filename, args.package, args.dry_run) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages installed_file.save() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", line 366, in save file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation)) IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' On Fri, Jan 13, 2017 at 4:08 PM, Nicky Perian wrote: > >>Documentation that it doesn't is of course welcome > > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall openjpeg > Traceback (most recent call last): > File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", > line 11, in > load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 263, in main > sys.exit(Autobuild().main(sys.argv[1:])) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 250, in main > tool_to_run.run(args) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 151, in run > uninstall_packages(args, installed_filename, args.package, > args.dry_run) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages > installed_file.save() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", > line 366, in save > file(self.path, 'wb').write(llsd.format_pretty_xml(dict_ > representation)) > IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua- > SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' > > On Fri, Jan 13, 2017 at 4:04 PM, Oz Linden (Scott Lawrence) < > oz at lindenlab.com> wrote: > >> On 2017-01-13 17:01 , Nicky Perian wrote: >> >> Does "autobuild uninstall xxxxx" work for autobuild-1.1? >> >> as far as we know, yes >> >> Documentation that it doesn't is of course welcome >> >> >> -- >> OZ LINDEN | Engineering Director, Second Life >> email or hangouts: 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/f4fc9963/attachment-0001.htm From nat at lindenlab.com Fri Jan 13 14:25:26 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Fri, 13 Jan 2017 17:25:26 -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 Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian wrote: Does "autobuild uninstall xxxxx" work for autobuild-1.1? > You might have to specify "autobuild uninstall --address-size 64 xxxxx" (or -A 64) for the autobuild uninstall command to select the correct build directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/6c38ad13/attachment.htm From nickyperian at gmail.com Fri Jan 13 14:53:52 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 13 Jan 2017 16:53:52 -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: and more... >>You might have to specify "autobuild uninstall --address-size 64 xxxxx" (or -A 64) for the autobuild uninstall command to >>select the correct build directory. (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32 uninstall openjpeg usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM] [-A {32,64}] {} ... autobuild: error: invalid choice: 'uninstall' (choose from ) and more ....... (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall --address-size 32 openjpeg Traceback (most recent call last): File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line 11, in load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 263, in main sys.exit(Autobuild().main(sys.argv[1:])) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", line 250, in main tool_to_run.run(args) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 151, in run uninstall_packages(args, installed_filename, args.package, args.dry_run) File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages installed_file.save() File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", line 366, in save file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation)) IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed wrote: > On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian > wrote: > > Does "autobuild uninstall xxxxx" work for autobuild-1.1? >> > > You might have to specify "autobuild uninstall --address-size 64 xxxxx" > (or -A 64) for the autobuild uninstall command to select the correct build > directory. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/503d2db3/attachment.htm From nickyperian at gmail.com Fri Jan 13 19:53:51 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 13 Jan 2017 21:53:51 -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: Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64 bit is worse. Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the same viewer with only openjpeg.dll changed. On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian wrote: > > and more... > >>You might have to specify "autobuild uninstall --address-size 64 xxxxx" > (or -A 64) for the autobuild uninstall command to >>select the correct > build directory. > > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32 > uninstall openjpeg > usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM] > [-A {32,64}] > {} ... > autobuild: error: invalid choice: 'uninstall' (choose from ) > > and more ....... > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall > --address-size 32 openjpeg > Traceback (most recent call last): > File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", > line 11, in > load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 263, in main > sys.exit(Autobuild().main(sys.argv[1:])) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 250, in main > tool_to_run.run(args) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 151, in run > uninstall_packages(args, installed_filename, args.package, > args.dry_run) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages > installed_file.save() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", > line 366, in save > file(self.path, 'wb').write(llsd.format_pretty_xml(dict_ > representation)) > IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua- > SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' > > On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed wrote: > >> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian >> wrote: >> >> Does "autobuild uninstall xxxxx" work for autobuild-1.1? >>> >> >> You might have to specify "autobuild uninstall --address-size 64 xxxxx" >> (or -A 64) for the autobuild uninstall command to select the correct build >> directory. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/eb49127d/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Openjpeg-1.5.1(32Bit).JPG Type: image/jpeg Size: 261239 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/eb49127d/attachment-0002.jpeg -------------- next part -------------- A non-text attachment was scrubbed... Name: OPenjpeg-1.4.0.JPG Type: image/jpeg Size: 269744 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170113/eb49127d/attachment-0003.jpeg From sldev at free.fr Sat Jan 14 01:58:07 2017 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 14 Jan 2017 10:58:07 +0100 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: Message-ID: <20170114105807.c78be7f614ddbd28fe645b24@free.fr> On Fri, 13 Jan 2017 21:53:51 -0600, Nicky Perian wrote: > Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64 > bit is worse. > Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the > same viewer with only openjpeg.dll changed. There are "fixes" that went into OpenJPEG v1.5 and newer, that break textures in SL (I posted in this list, long ago, about one such issue). However v1.5 and v2.0 bring security holes fixes and bug fixes. That's why I integrated the OpenJPEG v1.4 sources to my viewer (in indra/libopenjpeg/) and patched these sources with all the fixes I could find in v1.5 and v2.0 repositories and that are not ruining texture decoding in SL, as well as with a few more security checks (potential crash bug fixes) by me. Feel free to grab the Cool VL Viewer's "libopenjpeg" and integrate it in your own viewer. Regards, Henri. From nickyperian at gmail.com Mon Jan 16 03:47:26 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Mon, 16 Jan 2017 05:47:26 -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: @Nat https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 Please take this in and then provide for the updated archives in the viewer. I also received a report that the missing texture issue is in macOS when using openjpeg-1.5.1. Or, if the problem with 1.5.1 is easily corrected.... On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian wrote: > > and more... > >>You might have to specify "autobuild uninstall --address-size 64 xxxxx" > (or -A 64) for the autobuild uninstall command to >>select the correct > build directory. > > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32 > uninstall openjpeg > usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM] > [-A {32,64}] > {} ... > autobuild: error: invalid choice: 'uninstall' (choose from ) > > and more ....... > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall > --address-size 32 openjpeg > Traceback (most recent call last): > File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", > line 11, in > load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 263, in main > sys.exit(Autobuild().main(sys.argv[1:])) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 250, in main > tool_to_run.run(args) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 151, in run > uninstall_packages(args, installed_filename, args.package, > args.dry_run) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages > installed_file.save() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", > line 366, in save > file(self.path, 'wb').write(llsd.format_pretty_xml(dict_ > representation)) > IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua- > SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' > > On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed wrote: > >> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian >> wrote: >> >> Does "autobuild uninstall xxxxx" work for autobuild-1.1? >>> >> >> You might have to specify "autobuild uninstall --address-size 64 xxxxx" >> (or -A 64) for the autobuild uninstall command to select the correct build >> directory. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170116/a8044287/attachment.htm From michel.m.denis at gmail.com Mon Jan 16 10:39:55 2017 From: michel.m.denis at gmail.com (michel.m.denis) Date: Mon, 16 Jan 2017 18:39:55 +0000 Subject: [opensource-dev] =?utf-8?q?useful_info?= Message-ID: <1919331662.20170116213955@gmail.com> Hey! I've recently read some useful information, I guess it might be useful for you too, please read at http://pietro.patsmls.com/c1c0 All the best, michel.m.denis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170116/89ae785b/attachment.htm From nat at lindenlab.com Tue Jan 17 07:03:06 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Tue, 17 Jan 2017 10:03:06 -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 Mon, Jan 16, 2017 at 6:47 AM, Nicky Perian wrote: > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > Please take this in and then provide for the updated archives in the viewer. I also received a report that the missing texture issue is in macOS when using openjpeg-1.5.1. There are admittedly painful aspects to the two-step autobuild mechanism: (1) rebuild the 3p package and (2) update every consumer. However, one of the benefits of that approach is that we can adjust the version of a given 3p package consumed by (e.g.) the viewer without actually having to revert the 3p repository source. We can just change back the package URL specified in the viewer's autobuild.xml. > Or, if the problem with 1.5.1 is easily corrected.... Please forgive me if this should already be on my plate, but I don't recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load texture files that are correctly handled by 1.5.0? I think Cinder has a point: if we can move forward with 1.5.1, we should. From cinder at alchemyviewer.org Tue Jan 17 07:14:05 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Tue, 17 Jan 2017 15:14:05 +0000 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: Message-ID: <01000159acfe02d9-c8aeffaa-94db-4e92-b164-d480832ba2ee-000000@email.amazonses.com> We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can put together some patches to get it working. --? Cinder Roxley Sent with Airmail On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com ) wrote: Nat Goodspeed erian wrote: > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > Please take this in and then provide for the updated archives in the viewer. I also received a report that the missing texture issue is in macOS when using openjpeg-1.5.1. There are admittedly painful aspects to the two-step autobuild mechanism: (1) rebuild the 3p package and (2) update every consumer. However, one of the benefits of that approach is that we can adjust the version of a given 3p package consumed by (e.g.) the viewer without actually having to revert the 3p repository source. We can just change back the package URL specified in the viewer's autobuild.xml. > Or, if the problem with 1.5.1 is easily corrected.... Please forgive me if this should already be on my plate, but I don't recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load texture files that are correctly handled by 1.5.0? I think Cinder has a point: if we can move forward with 1.5.1, we should. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170117/0c5ef2b4/attachment.htm From nickyperian at gmail.com Tue Jan 17 09:09:21 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Tue, 17 Jan 2017 11:09:21 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: <01000159acfe02d9-c8aeffaa-94db-4e92-b164-d480832ba2ee-000000@email.amazonses.com> References: <01000159acfe02d9-c8aeffaa-94db-4e92-b164-d480832ba2ee-000000@email.amazonses.com> Message-ID: >>Please forgive me if this should already be on my plate, but I don't >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load >>texture files that are correctly handled by 1.5.0? Yes. openjpeg-1.5.1 has so many textures marked as over-sized and unavailable that the viewer is unusable. This came about with viewer64 as the default viewer is still on openjpeg-1.4.0. I had seen the same texture missing message once while using Project Alex Ivy viewer and filed a jira on that instance at https://jira.secondlife.com/browse/BUG-41228 . I am making a wild guess, but I think there is a possible CDN delivery issue that openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU. I had not known of openjpeg-1.5.0 every being supplied in a viewer or I would have certainly looked for it. On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley wrote: > We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can > put together some patches to get it working. > > -- > Cinder Roxley > Sent with Airmail > > On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com) > wrote: > > Nat Goodspeed erian wrote: > > > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > > > Please take this in and then provide for the updated archives in the > viewer. I also received a report that the missing texture issue is in macOS > when using openjpeg-1.5.1. > > There are admittedly painful aspects to the two-step autobuild > mechanism: (1) rebuild the 3p package and (2) update every consumer. > > However, one of the benefits of that approach is that we can adjust > the version of a given 3p package consumed by (e.g.) the viewer > without actually having to revert the 3p repository source. We can > just change back the package URL specified in the viewer's > autobuild.xml. > > > Or, if the problem with 1.5.1 is easily corrected.... > > Please forgive me if this should already be on my plate, but I don't > recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > texture files that are correctly handled by 1.5.0? > > I think Cinder has a point: if we can move forward with 1.5.1, we should. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > 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/20170117/5957c793/attachment.htm From desmoulins.uchi at googlemail.com Tue Jan 17 09:16:13 2017 From: desmoulins.uchi at googlemail.com (Niran) Date: Tue, 17 Jan 2017 18:16:13 +0100 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <01000159acfe02d9-c8aeffaa-94db-4e92-b164-d480832ba2ee-000000@email.amazonses.com> Message-ID: I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all that better... it was... unreliable. 2017-01-17 18:09 GMT+01:00 Nicky Perian : > >>Please forgive me if this should already be on my plate, but I don't > >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > >>texture files that are correctly handled by 1.5.0? > > Yes. > openjpeg-1.5.1 has so many textures marked as over-sized and unavailable > that the viewer is unusable. This came about with viewer64 as the default > viewer is still on openjpeg-1.4.0. I had seen the same texture missing > message once while using Project Alex Ivy viewer and filed a jira on that > instance at https://jira.secondlife.com/browse/BUG-41228 . I am making a > wild guess, but I think there is a possible CDN delivery issue that > openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU. > > I had not known of openjpeg-1.5.0 every being supplied in a viewer or I > would have certainly looked for it. > > > > > On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley > wrote: > >> We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can >> put together some patches to get it working. >> >> -- >> Cinder Roxley >> Sent with Airmail >> >> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com) >> wrote: >> >> Nat Goodspeed erian wrote: >> >> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 >> > >> > Please take this in and then provide for the updated archives in the >> viewer. I also received a report that the missing texture issue is in macOS >> when using openjpeg-1.5.1. >> >> There are admittedly painful aspects to the two-step autobuild >> mechanism: (1) rebuild the 3p package and (2) update every consumer. >> >> However, one of the benefits of that approach is that we can adjust >> the version of a given 3p package consumed by (e.g.) the viewer >> without actually having to revert the 3p repository source. We can >> just change back the package URL specified in the viewer's >> autobuild.xml. >> >> > Or, if the problem with 1.5.1 is easily corrected.... >> >> Please forgive me if this should already be on my plate, but I don't >> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load >> texture files that are correctly handled by 1.5.0? >> >> I think Cinder has a point: if we can move forward with 1.5.1, we should. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170117/e86253a4/attachment-0001.htm From flats_fixed at flatsfixedbicycles.com Thu Jan 19 14:57:52 2017 From: flats_fixed at flatsfixedbicycles.com (Brent Racobs) Date: Thu, 19 Jan 2017 16:57:52 -0600 Subject: [opensource-dev] opensource-dev Digest, Vol 78, Issue 20 In-Reply-To: References: Message-ID: autobuild is pretty lost OZ looking at it. It must be the linux part. Oh whats linux. looking at your 1.1 commits scratch my head. Then looks at build.sh wonders how that commit could do anything. pretty vacant commit what am I missing. On Tue, Jan 17, 2017 at 11:16 AM, < opensource-dev-request at lists.secondlife.com> wrote: > Send opensource-dev mailing list submissions to > opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/ > opensource-dev > or, via email, send a message with subject or body 'help' to > opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > 1. Re: 64 bit viewers build instructions (Nat Goodspeed) > 2. Re: 64 bit viewers build instructions (Cinder Roxley) > 3. Re: 64 bit viewers build instructions (Nicky Perian) > 4. Re: 64 bit viewers build instructions (Niran) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Jan 2017 10:03:06 -0500 > From: Nat Goodspeed > Subject: Re: [opensource-dev] 64 bit viewers build instructions > To: Nicky Perian > Cc: "opensource-dev at lists.secondlife.com" > > Message-ID: > gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Jan 16, 2017 at 6:47 AM, Nicky Perian > wrote: > > > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > > > Please take this in and then provide for the updated archives in the > viewer. I also received a report that the missing texture issue is in macOS > when using openjpeg-1.5.1. > > There are admittedly painful aspects to the two-step autobuild > mechanism: (1) rebuild the 3p package and (2) update every consumer. > > However, one of the benefits of that approach is that we can adjust > the version of a given 3p package consumed by (e.g.) the viewer > without actually having to revert the 3p repository source. We can > just change back the package URL specified in the viewer's > autobuild.xml. > > > Or, if the problem with 1.5.1 is easily corrected.... > > Please forgive me if this should already be on my plate, but I don't > recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > texture files that are correctly handled by 1.5.0? > > I think Cinder has a point: if we can move forward with 1.5.1, we should. > > > ------------------------------ > > Message: 2 > Date: Tue, 17 Jan 2017 15:14:05 +0000 > From: Cinder Roxley > Subject: Re: [opensource-dev] 64 bit viewers build instructions > To: opensource-dev at lists.secondlife.com > > Message-ID: > <01000159acfe02d9-c8aeffaa-94db-4e92-b164-d480832ba2ee- > 000000 at email.amazonses.com> > > Content-Type: text/plain; charset="utf-8" > > We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can > put together some patches to get it working. > > > --? > Cinder Roxley > Sent with Airmail > > > On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com > ) wrote: > > > Nat Goodspeed erian wrote: > > > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > > > Please take this in and then provide for the updated archives in the > viewer. I also received a report that the missing texture issue is in macOS > when using openjpeg-1.5.1. > > There are admittedly painful aspects to the two-step autobuild > mechanism: (1) rebuild the 3p package and (2) update every consumer. > > However, one of the benefits of that approach is that we can adjust > the version of a given 3p package consumed by (e.g.) the viewer > without actually having to revert the 3p repository source. We can > just change back the package URL specified in the viewer's > autobuild.xml. > > > Or, if the problem with 1.5.1 is easily corrected.... > > Please forgive me if this should already be on my plate, but I don't > recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > > texture files that are correctly handled by 1.5.0? > > I think Cinder has a point: if we can move forward with 1.5.1, we should. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/ > attachments/20170117/0c5ef2b4/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Tue, 17 Jan 2017 11:09:21 -0600 > From: Nicky Perian > Subject: Re: [opensource-dev] 64 bit viewers build instructions > To: Cinder Roxley > Cc: "opensource-dev at lists.secondlife.com" > > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > >>Please forgive me if this should already be on my plate, but I don't > >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > >>texture files that are correctly handled by 1.5.0? > > Yes. > openjpeg-1.5.1 has so many textures marked as over-sized and unavailable > that the viewer is unusable. This came about with viewer64 as the default > viewer is still on openjpeg-1.4.0. I had seen the same texture missing > message once while using Project Alex Ivy viewer and filed a jira on that > instance at https://jira.secondlife.com/browse/BUG-41228 . I am making a > wild guess, but I think there is a possible CDN delivery issue that > openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU. > > I had not known of openjpeg-1.5.0 every being supplied in a viewer or I > would have certainly looked for it. > > > > > On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley > wrote: > > > We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can > > put together some patches to get it working. > > > > -- > > Cinder Roxley > > Sent with Airmail > > > > On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com) > > wrote: > > > > Nat Goodspeed erian wrote: > > > > > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > > > > > > Please take this in and then provide for the updated archives in the > > viewer. I also received a report that the missing texture issue is in > macOS > > when using openjpeg-1.5.1. > > > > There are admittedly painful aspects to the two-step autobuild > > mechanism: (1) rebuild the 3p package and (2) update every consumer. > > > > However, one of the benefits of that approach is that we can adjust > > the version of a given 3p package consumed by (e.g.) the viewer > > without actually having to revert the 3p repository source. We can > > just change back the package URL specified in the viewer's > > autobuild.xml. > > > > > Or, if the problem with 1.5.1 is easily corrected.... > > > > Please forgive me if this should already be on my plate, but I don't > > recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > > texture files that are correctly handled by 1.5.0? > > > > I think Cinder has a point: if we can move forward with 1.5.1, we should. > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > > > _______________________________________________ > > 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/20170117/5957c793/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Tue, 17 Jan 2017 18:16:13 +0100 > From: Niran > Subject: Re: [opensource-dev] 64 bit viewers build instructions > To: Nicky Perian > Cc: "opensource-dev at lists.secondlife.com" > > Message-ID: > _vP3Uwg2DSiZ0g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all > that better... it was... unreliable. > > 2017-01-17 18:09 GMT+01:00 Nicky Perian : > > > >>Please forgive me if this should already be on my plate, but I don't > > >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > > >>texture files that are correctly handled by 1.5.0? > > > > Yes. > > openjpeg-1.5.1 has so many textures marked as over-sized and unavailable > > that the viewer is unusable. This came about with viewer64 as the default > > viewer is still on openjpeg-1.4.0. I had seen the same texture missing > > message once while using Project Alex Ivy viewer and filed a jira on that > > instance at https://jira.secondlife.com/browse/BUG-41228 . I am making > a > > wild guess, but I think there is a possible CDN delivery issue that > > openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU. > > > > I had not known of openjpeg-1.5.0 every being supplied in a viewer or I > > would have certainly looked for it. > > > > > > > > > > On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley > > > wrote: > > > >> We?ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can > >> put together some patches to get it working. > >> > >> -- > >> Cinder Roxley > >> Sent with Airmail > >> > >> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (nat at lindenlab.com) > >> wrote: > >> > >> Nat Goodspeed erian wrote: > >> > >> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 > >> > > >> > Please take this in and then provide for the updated archives in the > >> viewer. I also received a report that the missing texture issue is in > macOS > >> when using openjpeg-1.5.1. > >> > >> There are admittedly painful aspects to the two-step autobuild > >> mechanism: (1) rebuild the 3p package and (2) update every consumer. > >> > >> However, one of the benefits of that approach is that we can adjust > >> the version of a given 3p package consumed by (e.g.) the viewer > >> without actually having to revert the 3p repository source. We can > >> just change back the package URL specified in the viewer's > >> autobuild.xml. > >> > >> > Or, if the problem with 1.5.1 is easily corrected.... > >> > >> Please forgive me if this should already be on my plate, but I don't > >> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > >> texture files that are correctly handled by 1.5.0? > >> > >> I think Cinder has a point: if we can move forward with 1.5.1, we > should. > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > >> > >> _______________________________________________ > >> 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/ > attachments/20170117/e86253a4/attachment.htm > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 78, Issue 20 > ********************************************** > -- FLATS FIXED Emergency repairs flatsfixedbicycles.com This message has been sent by the most powerful bleeding edge operating system known to man SLACKWARE64-CURRENT We Get The Slack Back. It is free. Try it you will never go back just keep the slack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170119/836f1a0d/attachment-0001.htm From nickyperian at gmail.com Fri Jan 20 05:53:21 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 20 Jan 2017 07:53:21 -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: Moving on to Linux and Linux64. I noticed there isn't an archive for 3p-mesa for linux64. The one I have used for building linux64 on Kokua is very old. http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1-linux64-20081016.tar.bz2 Will this be updated for P64_3p-mesa? On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian wrote: > > and more... > >>You might have to specify "autobuild uninstall --address-size 64 xxxxx" > (or -A 64) for the autobuild uninstall command to >>select the correct > build directory. > > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32 > uninstall openjpeg > usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM] > [-A {32,64}] > {} ... > autobuild: error: invalid choice: 'uninstall' (choose from ) > > and more ....... > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall > --address-size 32 openjpeg > Traceback (most recent call last): > File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", > line 11, in > load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 263, in main > sys.exit(Autobuild().main(sys.argv[1:])) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 250, in main > tool_to_run.run(args) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 151, in run > uninstall_packages(args, installed_filename, args.package, > args.dry_run) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages > installed_file.save() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", > line 366, in save > file(self.path, 'wb').write(llsd.format_pretty_xml(dict_ > representation)) > IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua- > SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' > > On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed wrote: > >> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian >> wrote: >> >> Does "autobuild uninstall xxxxx" work for autobuild-1.1? >>> >> >> You might have to specify "autobuild uninstall --address-size 64 xxxxx" >> (or -A 64) for the autobuild uninstall command to select the correct build >> directory. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170120/42fede90/attachment.htm From nat at lindenlab.com Fri Jan 20 07:55:51 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Fri, 20 Jan 2017 10:55:51 -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 Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian wrote: Moving on to Linux and Linux64. > Now you're breaking trail. For the present, we're focusing on Windows and Mac. > I noticed there isn't an archive for 3p-mesa for linux64. > The one I have used for building linux64 on Kokua is very old. > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1- > linux64-20081016.tar.bz2 > > Will this be updated for P64_3p-mesa? > Let's talk about plans for Linux at the TPV meeting next week. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170120/921e2e4e/attachment.htm From nickyperian at gmail.com Sat Jan 28 19:00:13 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 28 Jan 2017 21:00:13 -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: macOS build ? Am I missing something? I have tried ReleaseOS command line build and cmake doesn't change to the correct source directory to complete the test compile. Are macOS command line builds possible at this time? On Fri, Jan 20, 2017 at 9:55 AM, Nat Goodspeed wrote: > On Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian > wrote: > > Moving on to Linux and Linux64. >> > > Now you're breaking trail. For the present, we're focusing on Windows and > Mac. > > >> I noticed there isn't an archive for 3p-mesa for linux64. >> The one I have used for building linux64 on Kokua is very old. >> http://s3.amazonaws.com/viewer-source-downloads/install_ >> pkgs/mesa-6.2.1-linux64-20081016.tar.bz2 >> >> Will this be updated for P64_3p-mesa? >> > > Let's talk about plans for Linux at the TPV meeting next week. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170128/9165e7ca/attachment.htm From nickyperian at gmail.com Sun Jan 29 17:39:10 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sun, 29 Jan 2017 19:39:10 -0600 Subject: [opensource-dev] Linux Message-ID: Questions: Will LL use a build system that can be updated as opposed to the current out of date system? Hopefully, the build system will be a standard off the shelf that everyone can install and without any mix and match specials. Will there be LL developed QA procedures for the linux builds? Granted, *.deb is a much used package manager for debian and derived distros. Will any other distro package managers be developed? I assume the answer is no so, will OS developer submissions of other package manager formats be accepted? Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170129/60c150c6/attachment.htm From monty at lindenlab.com Sun Jan 29 17:54:42 2017 From: monty at lindenlab.com (Monty Brandenberg) Date: Sun, 29 Jan 2017 20:54:42 -0500 Subject: [opensource-dev] Linux In-Reply-To: References: Message-ID: On 1/29/2017 8:39 PM, Nicky Perian wrote: > Will LL use a build system that can be updated as opposed to the current > out of date system? Hopefully, the build system will be a standard off > the shelf that everyone can install and without any mix and match specials. The "one, true Linux?" /me reaches for box of popcorn... From nickyperian at gmail.com Sun Jan 29 19:21:51 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sun, 29 Jan 2017 21:21:51 -0600 Subject: [opensource-dev] Linux In-Reply-To: References: Message-ID: >The "one, true Linux?" No not at all. Just something better. A few years ago Oz published a detailed recipe for your build system that was an original work by Donald Kjer. I can't find the reference atm but i would bet there isn't anyone besides Don that would be able to redo it from a blank box. On Sun, Jan 29, 2017 at 7:54 PM, Monty Brandenberg wrote: > On 1/29/2017 8:39 PM, Nicky Perian wrote: > > > Will LL use a build system that can be updated as opposed to the current > > out of date system? Hopefully, the build system will be a standard off > > the shelf that everyone can install and without any mix and match > specials. > > The "one, true Linux?" > > /me reaches for box of popcorn... > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170129/07a4b6ee/attachment.htm From sldev at free.fr Mon Jan 30 01:30:45 2017 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 30 Jan 2017 10:30:45 +0100 Subject: [opensource-dev] Linux In-Reply-To: References: Message-ID: <20170130103045.4f09f8502bbb6f2a412469b2@free.fr> On Sun, 29 Jan 2017 20:54:42 -0500, Monty Brandenberg wrote: > On 1/29/2017 8:39 PM, Nicky Perian wrote: > > > Will LL use a build system that can be updated as opposed to the current > > out of date system? Hopefully, the build system will be a standard off > > the shelf that everyone can install and without any mix and match specials. > > The "one, true Linux?" > > /me reaches for box of popcorn... /me steals popcorn in Monty's box, and speaks with a mouthful. /me chewing, "Ya know..." /me gulps, "Excuse me..." All it takes is writing a shell script allowing to build your viewer. Then packagers just have to invoke that script via whatever package build system you use (rpm, deb, ebuild, you name it). /me steals another handful of popcorn and points at his viewer sources Henri. From oz at lindenlab.com Mon Jan 30 08:23:23 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 30 Jan 2017 11:23:23 -0500 Subject: [opensource-dev] Linux In-Reply-To: References: Message-ID: <20ff4d10-e2c9-436c-6c64-986ac8ef8df3@lindenlab.com> On 2017-01-29 20:39 , Nicky Perian wrote: > Questions: > > Will LL use a build system that can be updated as opposed to the > current out of date system? Hopefully, the build system will be a > standard off the shelf that everyone can install and without any mix > and match specials. For the time being, we expect that it will be based on the current system, modified to use system libraries rather than autobuild packages that build a static executable (some packages will be used in our builds for proprietary components). I'm not sure that answers your question... > Will there be LL developed QA procedures for the linux builds? We'll use the same QA we've always used for Linux (not as much as we do for other platforms) > Granted, *.deb is a much used package manager for debian and derived > distros. Will any other distro package managers be developed? I assume > the answer is no so, will OS developer submissions of other package > manager formats be accepted? Let's worry about getting one to work... if we're wildly successful with that and there's a good reason to do something else, we'll discuss it. -- 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/20170130/e2ab39d7/attachment.htm From nat at lindenlab.com Mon Jan 30 08:37:22 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Mon, 30 Jan 2017 11:37:22 -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 Sat, Jan 28, 2017 at 10:00 PM, Nicky Perian wrote: macOS build ? > Am I missing something? I have tried ReleaseOS command line build and > cmake doesn't change to the correct source directory to complete the test > compile. > > Are macOS command line builds possible at this time? > I think what you're encountering is that there is no longer a 'darwin' platform in viewer64/autobuild.xml, only 'darwin64'. If you use 'autobuild configure -A 64' (or leave AUTOBUILD_ADDRSIZE=64 set in your environment) it should work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170130/52566a7a/attachment-0001.htm From sl.nicky.ml at googlemail.com Mon Jan 30 09:41:07 2017 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Mon, 30 Jan 2017 18:41:07 +0100 Subject: [opensource-dev] Linux In-Reply-To: <20ff4d10-e2c9-436c-6c64-986ac8ef8df3@lindenlab.com> References: <20ff4d10-e2c9-436c-6c64-986ac8ef8df3@lindenlab.com> Message-ID: > > For the time being, we expect that it will be based on the current system, > modified to use system libraries rather than autobuild packages that build a > static executable (some packages will be used in our builds for proprietary > components). I'm not sure that answers your question... > This is the old Squeeze based Debian? > Granted, *.deb is a much used package manager for debian and derived > distros. Will any other distro package managers be developed? I assume the > answer is no so, will OS developer submissions of other package manager > formats be accepted? > > Let's worry about getting one to work... if we're wildly successful with > that and there's a good reason to do something else, we'll discuss it. I'm not sure yet what to make out of this change, as we possible need to see a deb to see about some of the consequences. Just a few thoughts: - Standalone is afaik broken since a long time, for example there is missing FindXXX.cmake files for various packages. - As far as I know are there no system packages for (at least) glod, colladadom, breakpad and cef. - Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example I cannot find anything older than 2 for Debian Wheezy). Possibly this can be worked around with non standard deb repositories in apt.conf. - Compiling the deb eg on Squeeze and trying to install it on something Wheezy based could lead to interesting results, due to the dependent packages from the Squeeze system being recorded in the deb. (Or compiling on Wheezy and installing on Jessie and so on). - VLC: Henri pointed out a few times, that the VLC api is not exactly stable between releases. - Boost will be interesting From sldev at free.fr Mon Jan 30 09:55:38 2017 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 30 Jan 2017 18:55:38 +0100 Subject: [opensource-dev] List archive down ? Message-ID: <20170130185538.14eadb0165d6ab8515448cdc@free.fr> Greetings, It's been a couple of weeks that I noticed it: the archive site for this list seems to be down: https://lists.secondlife.com/pipermail/opensource-dev/ reports "Unable to connect"... Did the address change (it's still the one listed on the Wiki) or is this a problem with a badly configured server ? Henri. From kirstiemc555 at hotmail.co.uk Mon Jan 30 10:38:40 2017 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Mon, 30 Jan 2017 18:38:40 +0000 Subject: [opensource-dev] List archive down ? In-Reply-To: <20170130185538.14eadb0165d6ab8515448cdc@free.fr> References: <20170130185538.14eadb0165d6ab8515448cdc@free.fr> Message-ID: I filed a bug report for this & was told it was a known issue. https://jira.secondlife.com/browse/BUG-41243 - https://lists.secondlife.com/ is down ________________________________ From: opensource-dev-bounces at lists.secondlife.com on behalf of Henri Beauchamp Sent: 30 January 2017 17:55 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] List archive down ? Greetings, It's been a couple of weeks that I noticed it: the archive site for this list seems to be down: https://lists.secondlife.com/pipermail/opensource-dev/ reports "Unable to connect"... Did the address change (it's still the one listed on the Wiki) or is this a problem with a badly configured server ? Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev OpenSource-Dev - Second Life Wiki wiki.secondlife.com Posting Policies and Guidelines. The opensource-dev mailing list is for development issue related to Second Life open source code. The following policies ... 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/20170130/f5fec0c0/attachment.htm From kirstiemc555 at hotmail.co.uk Mon Jan 30 10:42:00 2017 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Mon, 30 Jan 2017 18:42:00 +0000 Subject: [opensource-dev] List archive down ? In-Reply-To: References: <20170130185538.14eadb0165d6ab8515448cdc@free.fr>, Message-ID: ...and as if by magic, https://lists.secondlife.com/pipermail/opensource-dev/ is back up... ________________________________ From: opensource-dev-bounces at lists.secondlife.com on behalf of Whirly Fizzle Sent: 30 January 2017 18:38 To: Henri Beauchamp; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] List archive down ? I filed a bug report for this & was told it was a known issue. https://jira.secondlife.com/browse/BUG-41243 - https://lists.secondlife.com/ is down ________________________________ From: opensource-dev-bounces at lists.secondlife.com on behalf of Henri Beauchamp Sent: 30 January 2017 17:55 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] List archive down ? Greetings, It's been a couple of weeks that I noticed it: the archive site for this list seems to be down: https://lists.secondlife.com/pipermail/opensource-dev/ reports "Unable to connect"... Did the address change (it's still the one listed on the Wiki) or is this a problem with a badly configured server ? Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev OpenSource-Dev - Second Life Wiki wiki.secondlife.com Posting Policies and Guidelines. The opensource-dev mailing list is for development issue related to Second Life open source code. The following policies ... 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/20170130/27252437/attachment.htm From sldev at free.fr Mon Jan 30 11:04:14 2017 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 30 Jan 2017 20:04:14 +0100 Subject: [opensource-dev] Linux In-Reply-To: References: <20ff4d10-e2c9-436c-6c64-986ac8ef8df3@lindenlab.com> Message-ID: <20170130200414.f651f29d3e339a269a01b53c@free.fr> On Mon, 30 Jan 2017 18:41:07 +0100, Nicky D. wrote: > - Standalone is afaik broken since a long time, for example there is > missing FindXXX.cmake files for various packages. Many such files are actually part of the cmake package or added by the devel packages of some libraries. See: /usr/share/cmake/Modules/Find* > - As far as I know are there no system packages for (at least) glod, > colladadom, breakpad and cef. > > - Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example > I cannot find anything older than 2 > for Debian Wheezy). Possibly this can be worked around with non > standard deb repositories in apt.conf. > > - Compiling the deb eg on Squeeze and trying to install it on > something Wheezy based could lead to > interesting results, due to the dependent packages from the Squeeze > system being recorded in the deb. > (Or compiling on Wheezy and installing on Jessie and so on). I resolved the "STANDALONE" (now "SYSTEMLIBS") issue for my viewer by making it so that libraries that are not likely to be present in distros, or not properly patched for SL viewers, or simply incompatible, are still downloaded as the pre-built viewer libraries (i.e. the resulting viewer binary is linked against a mix of commonly available system libraries and exotic/patched pre-built libraries). It more or less works, i.e. it works on my system (PCLinuxOS) but one of my users encountered an issue with this method recently (probably because of his distro's curl library, which I will probably mark as "use-pre-built-curl-only" in future releases). Your best bet is however to keep building the viewer using the pre-built libraries and packaging it together with them (/usr/games/YourViewerName is a good candidate for the packaged build destination). > - VLC: Henri pointed out a few times, that the VLC api is not exactly > stable between releases. Gstreamer would be better... I would have pointed you to the archived messages on this list in which I went to great extents to explain everything in details, but the archive is currently down... > - Boost will be interesting You cannot currently using system boost libraries: they lack LL's custom coroutine stuff... Henri. From oz at lindenlab.com Mon Jan 30 15:37:49 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 30 Jan 2017 18:37:49 -0500 Subject: [opensource-dev] Linux In-Reply-To: References: <20ff4d10-e2c9-436c-6c64-986ac8ef8df3@lindenlab.com> Message-ID: <4a74f4d6-835b-70fe-f31f-5de197cf37f9@lindenlab.com> On 2017-01-30 12:41 , Nicky D. wrote: >> For the time being, we expect that it will be based on the current system, >> modified to use system libraries rather than autobuild packages that build a >> static executable (some packages will be used in our builds for proprietary >> components). I'm not sure that answers your question... >> > This is the old Squeeze based Debian? No, we're going to leapfrog to Jessie for this. >> Granted, *.deb is a much used package manager for debian and derived >> distros. Will any other distro package managers be developed? I assume the >> answer is no so, will OS developer submissions of other package manager >> formats be accepted? >> >> Let's worry about getting one to work... if we're wildly successful with >> that and there's a good reason to do something else, we'll discuss it. > I'm not sure yet what to make out of this change, as we possible need > to see a deb to see > about some of the consequences. Just a few thoughts: > > - Standalone is afaik broken since a long time, for example there is > missing FindXXX.cmake > files for various packages. > > - As far as I know are there no system packages for (at least) glod, > colladadom, breakpad and cef. > > - Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example > I cannot find anything older than 2 > for Debian Wheezy). Possibly this can be worked around with non > standard deb repositories in apt.conf. > > - Compiling the deb eg on Squeeze and trying to install it on > something Wheezy based could lead to > interesting results, due to the dependent packages from the Squeeze > system being recorded in the deb. > (Or compiling on Wheezy and installing on Jessie and so on). > > - VLC: Henri pointed out a few times, that the VLC api is not exactly > stable between releases. > > - Boost will be interesting Well, if it was easy it wouldn't be any fun, would it? -- 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/20170130/73d930ef/attachment.htm From geir.noklebye at dayturn.com Tue Jan 31 02:55:13 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Tue, 31 Jan 2017 11:55:13 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <197E8CC4-417C-439E-AEE4-0231243277C4@dayturn.com> Are you all aware of the Apple maintained opensource libraries already included in macOS that you also maintain and use in the viewer? Examples are libexpat, pcre, openAL, hunspell and openssl. It might be easier to build the macOS version of the viewer with these libraries, rather than spend (a lot of) effort on maintaining them for macOS on your own. Opensource that is included in every version of macOS is listed on https://opensource.apple.com with code to be downloaded. In addition there are the system framework image handling dylibs in /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/Resources/ Cheers, Geir N?klebye aka Gavin Hird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170131/62ebbe35/attachment.htm From cinder at alchemyviewer.org Tue Jan 31 04:05:53 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Tue, 31 Jan 2017 12:05:53 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <197E8CC4-417C-439E-AEE4-0231243277C4@dayturn.com> References: <197E8CC4-417C-439E-AEE4-0231243277C4@dayturn.com> Message-ID: <01000159f46abe46-afa83f5f-857c-4ac7-a983-2e4f55ee2dbb-000000@email.amazonses.com> On January 31, 2017 at 4:55:26 AM, Geir N?klebye (geir.noklebye at dayturn.com ) wrote: Are you all aware of the Apple maintained opensource libraries already included in macOS that you also maintain and use in the viewer? ?Examples are libexpat, pcre, openAL, hunspell and openssl. Most of which are woefully out of date. --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170131/db2fcc4e/attachment.htm From geir.noklebye at dayturn.com Tue Jan 31 12:12:13 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Tue, 31 Jan 2017 21:12:13 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: Message-ID: <453B035B-B07C-4AD9-BDE6-341AACDD0D77@dayturn.com> Some are outdated and some are more up to date than the current viewer libraries. They usually get serious amount of public flack if security issues are not fixed, meaning they are automatically patched when users upgrade their systems. ? The other thing is they are all compiled both 32 and 64 bit so they can be used for either architecture. ? Equally important is they are battle tested on tens of millions of macOS installs. ? They also build with the latest development tools (unless they are ancient such as OpenAL that needs Carbon, and only will build 32 bit.) From cinder at alchemyviewer.org Tue Jan 31 12:24:41 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Tue, 31 Jan 2017 20:24:41 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <453B035B-B07C-4AD9-BDE6-341AACDD0D77@dayturn.com> References: Message-ID: <01000159f6336990-b4ec3a45-edff-4a4b-8c25-9d9c81174145-000000@email.amazonses.com> On January 31, 2017 at 2:12:24 PM, Geir N?klebye (geir.noklebye at dayturn.com ) wrote: Some are outdated and some are more up to date than the current viewer libraries.? They usually get serious amount of public flack if security issues are not fixed, meaning they are automatically patched when users upgrade their systems.? ~ % otool -L /usr/lib/libssl.dylib /usr/lib/libssl.dylib: /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) I rest my case. Plus, the majority of libraries consumed by the viewer don?t offer api compatibility between versions making cross-platform development, not to mention QA, all the more painful. --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170131/c7a1f2c0/attachment.htm From monty at lindenlab.com Tue Jan 31 12:40:36 2017 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 31 Jan 2017 15:40:36 -0500 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <01000159f6336990-b4ec3a45-edff-4a4b-8c25-9d9c81174145-000000@email.amazonses.com> References: <01000159f6336990-b4ec3a45-edff-4a4b-8c25-9d9c81174145-000000@email.amazonses.com> Message-ID: <7df42f0c-7d5c-30e3-b07a-d1e0a8206bbd@lindenlab.com> On 1/31/2017 3:24 PM, Cinder Roxley wrote: > ~ % otool -L /usr/lib/libssl.dylib > > /usr/lib/libssl.dylib: > > /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) > > /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) Ouch. I was ashamed of how long we stayed at 0.9.8. (Would kinda like to use LibreSSL...) -- 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 cinder at alchemyviewer.org Tue Jan 31 12:52:27 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Tue, 31 Jan 2017 20:52:27 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <7df42f0c-7d5c-30e3-b07a-d1e0a8206bbd@lindenlab.com> References: Message-ID: <01000159f64cd57c-b1ac5c26-455a-42e1-bda9-9c6c4887cf59-000000@email.amazonses.com> On January 31, 2017 at 2:40:44 PM, Monty Brandenberg (monty at lindenlab.com ) wrote: On 1/31/2017 3:24 PM, Cinder Roxley wrote: > ~ % otool -L /usr/lib/libssl.dylib > > /usr/lib/libssl.dylib: > > /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) > > /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) Ouch. I was ashamed of how long we stayed at 0.9.8. (Would kinda like to use LibreSSL...) For what it?s worth, Apple did warn developers to stop using it and switch to Cocoa?s crypto frameworks or ship their own. I?ve been waiting for a peer review of BearSSL myself. --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170131/8fa1b697/attachment.htm