[Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi, Can we push our exr to 2.0? (+oiio +ocio +osl - due to dependancies) I know we just recently updated it to 1.7.1 but 2.0 just came out with multipart support. Blender (trunk) itself will not benefit from it immediately, but the multiview branch [1] requires exr 2.0. I don't know if part of the branch can be ready for 2.68, but regardless it's important for me to have users testing it. To have users building their own libraries is a bit too much to ask, thus my request. I don't mind if we have to wait for after an eventual 2.67a. As long as we can agree on the need for the push. [1] - http://lists.blender.org/pipermail/bf-committers/2013-May/040116.html Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] platform maintainers: request to update exr lib to 2.0
Hey there, compiling OpenEXR 2.0.0 and the dependent libs took me all day, so I had no time to compile the VS2010 libs :( I am currently uploading the whole bunch, this could take a while because my internet connection is darn slow. So stay tuned for the SVN commit mail ;) /Jürgen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Some questions were raised no IRC, let me clarify some things: Q: What does it change when we update for 2.0? A: Nothing, absolutely nothing. The saved files will be the same as before, and the same goes for reading. As long as we don't change the Blender code the changes will be invisible for the user/devs. Q: What is new in EXR 2.0 A: Mainly Multipart support and Depth Data - from http://www.openexr.com : " Deep Data. Pixels can now store a variable length list of samples. The main rationale behind deep-images is to store multiple values at different depths for each pixel. Support for hard surface and volumetric representation requirements for deep compositing workflows. Multi-part image files. Files can now contain a number of separate, but related, images in one file. Access to any part is independent of the others; in particular, no access of data need take place for unrequested parts. " Q: Shouldn't we wait for EXR 2.0.1 ? A: OpenEXR is been used by many industry stockholders (ILM, Weta, ...). That doesn't mean openexr is bug-free, but they do have auto-test code and a Quality and Assurance teams (I'm guessing on the later, but still). Q: Why do we need EXR 2.0? (or better, why do the multiview branch needs it) A.1: To Read-Write the new defacto standard for stereoscopic files. A.2: To be honest, OpenEXR 1.7.1 already supported MutliView (aka stereo 3d), so at first I thought I wouldn't need that. However I couldn't get "Save Buffers" or the "FSA" options to work with it. With the old MultiView format we need to have all the channels of all the views ready at once, in order to write to the file. With MultiPart we can open the file, render one view, write one view, render another view, write another view, and then close the file. I hope that explains things. Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, I'll be building soon for the MinGW systems. Is the python part of the library required? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, I could provide builds for Vc2008 and VC2012 after the 2.67a release. Just some questions: - Do we have to recompile other libs that depend on OpenEXR too? OSL for example relies on it. - As we don't have boost python in the boost libs I guess we won't need the python part in OpenEXR, right? /Jürgen Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis : > Hi Dalai, I'll be building soon for the MinGW systems. Is the python part > of the library required? > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi, I don't see why we would need the python part of it. Basically the same build settings we used for 1.71 should be used for 2.0 I believe. And yes other libs that depend on it will need to be recompiled: That means primary openimageio. But I also believe OSL and OCIO are needed (they depend on OIIO). [here I only built exr and oiio, but then I'm building with no osl/ocio] I'm not sure there is any other library (or even if ocio needs it). Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/5/15 Jürgen Herrmann > Hi Dalai, > > I could provide builds for Vc2008 and VC2012 after the 2.67a release. > Just some questions: > - Do we have to recompile other libs that depend on OpenEXR too? > OSL for example relies on it. > - As we don't have boost python in the boost libs I guess we won't need > the python part in OpenEXR, right? > > /Jürgen > > Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis : > > > Hi Dalai, I'll be building soon for the MinGW systems. Is the python part > > of the library required? > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Actually i'm really skeptical about such a bump. That'd introduce extra pain building blender on linux -- seems only gentoo and arch switched to openexr 2.0. Also, some of the distros like ubuntu and fedora contains openimageio, which is for sure linked against distro's openexr 1.6. This is all leads to really spaghetti changes and would rather see updates for build instructions and probably install dependencies script before we'll bump openexr version required for blender. P.S. In any way, this will also be a PITA for distros maintainers :( On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto wrote: > Hi, > > I don't see why we would need the python part of it. > Basically the same build settings we used for 1.71 should be used for 2.0 I > believe. > > And yes other libs that depend on it will need to be recompiled: > That means primary openimageio. But I also believe OSL and OCIO are needed > (they depend on OIIO). > [here I only built exr and oiio, but then I'm building with no osl/ocio] > > I'm not sure there is any other library (or even if ocio needs it). > > Thanks, > Dalai > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/5/15 Jürgen Herrmann > > > Hi Dalai, > > > > I could provide builds for Vc2008 and VC2012 after the 2.67a release. > > Just some questions: > > - Do we have to recompile other libs that depend on OpenEXR too? > > OSL for example relies on it. > > - As we don't have boost python in the boost libs I guess we won't need > > the python part in OpenEXR, right? > > > > /Jürgen > > > > Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis : > > > > > Hi Dalai, I'll be building soon for the MinGW systems. Is the python > part > > > of the library required? > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
We've discussed it in IRC today. Conclusion is: 1. Windows/OSX libs are safe for update, wouldn't lead to issues and platform maintainers could just go ahead 2. I'll update linux build environment during next week. 3. Before merge the code to trunk, we'll need to update wiki page with building instructions and update install_deps.sh. If nobody volunteers to help updating the script, i'll try to update it over next week (or two) 4. Then we're safe for merge :) Could still cause some PITA for distros maintainers tho, but eeh.. Krita will also require openexr2.0 soon so afraid the only way (apart from disabling openexr support) would be to include openexr2.0 libs to repos... On Fri, May 17, 2013 at 6:59 PM, Sergey Sharybin wrote: > Actually i'm really skeptical about such a bump. That'd introduce extra > pain building blender on linux -- seems only gentoo and arch switched to > openexr 2.0. > > Also, some of the distros like ubuntu and fedora contains openimageio, > which is for sure linked against distro's openexr 1.6. > > This is all leads to really spaghetti changes and would rather see updates > for build instructions and probably install dependencies script before > we'll bump openexr version required for blender. > > P.S. In any way, this will also be a PITA for distros maintainers :( > > > On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto wrote: > >> Hi, >> >> I don't see why we would need the python part of it. >> Basically the same build settings we used for 1.71 should be used for 2.0 >> I >> believe. >> >> And yes other libs that depend on it will need to be recompiled: >> That means primary openimageio. But I also believe OSL and OCIO are needed >> (they depend on OIIO). >> [here I only built exr and oiio, but then I'm building with no osl/ocio] >> >> I'm not sure there is any other library (or even if ocio needs it). >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/5/15 Jürgen Herrmann >> >> > Hi Dalai, >> > >> > I could provide builds for Vc2008 and VC2012 after the 2.67a release. >> > Just some questions: >> > - Do we have to recompile other libs that depend on OpenEXR too? >> > OSL for example relies on it. >> > - As we don't have boost python in the boost libs I guess we won't need >> > the python part in OpenEXR, right? >> > >> > /Jürgen >> > >> > Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis : >> > >> > > Hi Dalai, I'll be building soon for the MinGW systems. Is the python >> part >> > > of the library required? >> > > ___ >> > > Bf-committers mailing list >> > > Bf-committers@blender.org >> > > http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
I should be able to see for install_deps.sh next week… ;) Bastien On 17/05/2013 20:36, Sergey Sharybin wrote: > We've discussed it in IRC today. Conclusion is: > > 1. Windows/OSX libs are safe for update, wouldn't lead to issues and > platform maintainers could just go ahead > 2. I'll update linux build environment during next week. > 3. Before merge the code to trunk, we'll need to update wiki page with > building instructions and update install_deps.sh. If nobody volunteers to > help updating the script, i'll try to update it over next week (or two) > 4. Then we're safe for merge :) > > Could still cause some PITA for distros maintainers tho, but eeh.. Krita > will also require openexr2.0 soon so afraid the only way (apart from > disabling openexr support) would be to include openexr2.0 libs to repos... > > > On Fri, May 17, 2013 at 6:59 PM, Sergey Sharybinwrote: > >> Actually i'm really skeptical about such a bump. That'd introduce extra >> pain building blender on linux -- seems only gentoo and arch switched to >> openexr 2.0. >> >> Also, some of the distros like ubuntu and fedora contains openimageio, >> which is for sure linked against distro's openexr 1.6. >> >> This is all leads to really spaghetti changes and would rather see updates >> for build instructions and probably install dependencies script before >> we'll bump openexr version required for blender. >> >> P.S. In any way, this will also be a PITA for distros maintainers :( >> >> >> On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto wrote: >> >>> Hi, >>> >>> I don't see why we would need the python part of it. >>> Basically the same build settings we used for 1.71 should be used for 2.0 >>> I >>> believe. >>> >>> And yes other libs that depend on it will need to be recompiled: >>> That means primary openimageio. But I also believe OSL and OCIO are needed >>> (they depend on OIIO). >>> [here I only built exr and oiio, but then I'm building with no osl/ocio] >>> >>> I'm not sure there is any other library (or even if ocio needs it). >>> >>> Thanks, >>> Dalai >>> -- >>> blendernetwork.org/member/dalai-felinto >>> www.dalaifelinto.com >>> >>> >>> 2013/5/15 Jürgen Herrmann >>> Hi Dalai, I could provide builds for Vc2008 and VC2012 after the 2.67a release. Just some questions: - Do we have to recompile other libs that depend on OpenEXR too? OSL for example relies on it. - As we don't have boost python in the boost libs I guess we won't need the python part in OpenEXR, right? /Jürgen Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis: > Hi Dalai, I'll be building soon for the MinGW systems. Is the python >>> part > of the library required? > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> -- >> With best regards, Sergey Sharybin >> > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
For the records, OSX libs are already committed and working fine (thanks Jens). For windows/linux the libs we will need are: openexr, openimageio and openshadinglanguage. opencolorio does not need to be updated. Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/5/17 Bastien Montagne > I should be able to see for install_deps.sh next week… ;) > > Bastien > > On 17/05/2013 20:36, Sergey Sharybin wrote: > > We've discussed it in IRC today. Conclusion is: > > > > 1. Windows/OSX libs are safe for update, wouldn't lead to issues and > > platform maintainers could just go ahead > > 2. I'll update linux build environment during next week. > > 3. Before merge the code to trunk, we'll need to update wiki page with > > building instructions and update install_deps.sh. If nobody volunteers to > > help updating the script, i'll try to update it over next week (or two) > > 4. Then we're safe for merge :) > > > > Could still cause some PITA for distros maintainers tho, but eeh.. Krita > > will also require openexr2.0 soon so afraid the only way (apart from > > disabling openexr support) would be to include openexr2.0 libs to > repos... > > > > > > On Fri, May 17, 2013 at 6:59 PM, Sergey Sharybin >wrote: > > > >> Actually i'm really skeptical about such a bump. That'd introduce extra > >> pain building blender on linux -- seems only gentoo and arch switched to > >> openexr 2.0. > >> > >> Also, some of the distros like ubuntu and fedora contains openimageio, > >> which is for sure linked against distro's openexr 1.6. > >> > >> This is all leads to really spaghetti changes and would rather see > updates > >> for build instructions and probably install dependencies script before > >> we'll bump openexr version required for blender. > >> > >> P.S. In any way, this will also be a PITA for distros maintainers :( > >> > >> > >> On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto > wrote: > >> > >>> Hi, > >>> > >>> I don't see why we would need the python part of it. > >>> Basically the same build settings we used for 1.71 should be used for > 2.0 > >>> I > >>> believe. > >>> > >>> And yes other libs that depend on it will need to be recompiled: > >>> That means primary openimageio. But I also believe OSL and OCIO are > needed > >>> (they depend on OIIO). > >>> [here I only built exr and oiio, but then I'm building with no > osl/ocio] > >>> > >>> I'm not sure there is any other library (or even if ocio needs it). > >>> > >>> Thanks, > >>> Dalai > >>> -- > >>> blendernetwork.org/member/dalai-felinto > >>> www.dalaifelinto.com > >>> > >>> > >>> 2013/5/15 Jürgen Herrmann > >>> > Hi Dalai, > > I could provide builds for Vc2008 and VC2012 after the 2.67a release. > Just some questions: > - Do we have to recompile other libs that depend on OpenEXR too? > OSL for example relies on it. > - As we don't have boost python in the boost libs I guess we won't > need > the python part in OpenEXR, right? > > /Jürgen > > Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis: > > > Hi Dalai, I'll be building soon for the MinGW systems. Is the python > >>> part > > of the library required? > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > > >>> ___ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> > >> > >> -- > >> With best regards, Sergey Sharybin > >> > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Jurgen, Is the new EXR2.0 entirely updated for windows32 and 64 (MSVC9 - cmake and scons)? I'm a bit confused by all the sparse emails on the latest windows libraries and building systems updates. I'm having a segfault on windows for some builds of the multiview branch (building with scons if I'm not mistaken) when opening a multiview/multipart exr. The same does not happen in OSX. And when I built with cmake+msvc9+debug the error was gone. I thought the problem was in my setup, but the same happens with the BuilderBot multiview build: * http://builder.blender.org/download/ (multiview is the last in the list) * http://svn.blender.org/svnroot/bf-blender/branches/multiview/ (code in svn if you want to test) * https://github.com/dfelinto/blender/blob/multiview/samples/images/caminandes_new_edit.exr?raw=true (sample file) I will keep looking at it, but it would help to know whether it was supposed to work or if the libs/build setup are still work in progress. Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/5/17 Dalai Felinto : > For the records, OSX libs are already committed and working fine (thanks > Jens). > > For windows/linux the libs we will need are: openexr, openimageio and > openshadinglanguage. > opencolorio does not need to be updated. > > Thanks, > Dalai > > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/5/17 Bastien Montagne >> >> I should be able to see for install_deps.sh next week… ;) >> >> Bastien >> >> On 17/05/2013 20:36, Sergey Sharybin wrote: >> > We've discussed it in IRC today. Conclusion is: >> > >> > 1. Windows/OSX libs are safe for update, wouldn't lead to issues and >> > platform maintainers could just go ahead >> > 2. I'll update linux build environment during next week. >> > 3. Before merge the code to trunk, we'll need to update wiki page with >> > building instructions and update install_deps.sh. If nobody volunteers >> > to >> > help updating the script, i'll try to update it over next week (or two) >> > 4. Then we're safe for merge :) >> > >> > Could still cause some PITA for distros maintainers tho, but eeh.. Krita >> > will also require openexr2.0 soon so afraid the only way (apart from >> > disabling openexr support) would be to include openexr2.0 libs to >> > repos... >> > >> > >> > On Fri, May 17, 2013 at 6:59 PM, Sergey >> > Sharybinwrote: >> > >> >> Actually i'm really skeptical about such a bump. That'd introduce extra >> >> pain building blender on linux -- seems only gentoo and arch switched >> >> to >> >> openexr 2.0. >> >> >> >> Also, some of the distros like ubuntu and fedora contains openimageio, >> >> which is for sure linked against distro's openexr 1.6. >> >> >> >> This is all leads to really spaghetti changes and would rather see >> >> updates >> >> for build instructions and probably install dependencies script before >> >> we'll bump openexr version required for blender. >> >> >> >> P.S. In any way, this will also be a PITA for distros maintainers :( >> >> >> >> >> >> On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto >> >> wrote: >> >> >> >>> Hi, >> >>> >> >>> I don't see why we would need the python part of it. >> >>> Basically the same build settings we used for 1.71 should be used for >> >>> 2.0 >> >>> I >> >>> believe. >> >>> >> >>> And yes other libs that depend on it will need to be recompiled: >> >>> That means primary openimageio. But I also believe OSL and OCIO are >> >>> needed >> >>> (they depend on OIIO). >> >>> [here I only built exr and oiio, but then I'm building with no >> >>> osl/ocio] >> >>> >> >>> I'm not sure there is any other library (or even if ocio needs it). >> >>> >> >>> Thanks, >> >>> Dalai >> >>> -- >> >>> blendernetwork.org/member/dalai-felinto >> >>> www.dalaifelinto.com >> >>> >> >>> >> >>> 2013/5/15 Jürgen Herrmann >> >>> >> Hi Dalai, >> >> I could provide builds for Vc2008 and VC2012 after the 2.67a release. >> Just some questions: >> - Do we have to recompile other libs that depend on OpenEXR too? >> OSL for example relies on it. >> - As we don't have boost python in the boost libs I guess we won't >> need >> the python part in OpenEXR, right? >> >> /Jürgen >> >> Am 15.05.2013 um 20:31 schrieb Antony Riakiotakis: >> >> > Hi Dalai, I'll be building soon for the MinGW systems. Is the python >> >>> part >> > of the library required? >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >>> ___ >> >>> Bf-committers mailing list >> >>> Bf-committers@blender.org >> >>> http://lists.blender.org/mailman/l
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, The EXR libs are entirely updated to 2.0. I am having problems with scons too but I accounted this to my absolute inability to be friends with scons ;) you said the error is gone when you build with cmake so it's probably a problem with scons because the libs are the same for both build systems. Maybe a missing define or a wrong lib, different compiler options/optimization? I just don't get to like it and it seems that scons config for windows/msvc builds are always subject to problems. If you build blender with cmake things work much better for a reason I don't understand. If I were in charge for the build systems I would drop scons completely in favor of cmake, but I am not in charge so just forget I mentioned this. It is much harder to adapt new build targets with scons than with cmake. The scripts are quite complex so that new developers like me need to spend much time on build system logic instead of having time to really do work on blender itself. /Jürgen Am 01.06.2013 um 22:39 schrieb Dalai Felinto : > Hi Jurgen, > > Is the new EXR2.0 entirely updated for windows32 and 64 (MSVC9 - cmake > and scons)? > I'm a bit confused by all the sparse emails on the latest windows > libraries and building systems updates. > > I'm having a segfault on windows for some builds of the multiview > branch (building with scons if I'm not mistaken) when opening a > multiview/multipart exr. The same does not happen in OSX. And when I > built with cmake+msvc9+debug the error was gone. > > I thought the problem was in my setup, but the same happens with the > BuilderBot multiview build: > > * http://builder.blender.org/download/ (multiview is the last in the list) > * http://svn.blender.org/svnroot/bf-blender/branches/multiview/ (code > in svn if you want to test) > * > https://github.com/dfelinto/blender/blob/multiview/samples/images/caminandes_new_edit.exr?raw=true > (sample file) > > I will keep looking at it, but it would help to know whether it was > supposed to work or if the libs/build setup are still work in > progress. > > Thanks, > Dalai > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/5/17 Dalai Felinto : >> For the records, OSX libs are already committed and working fine (thanks >> Jens). >> >> For windows/linux the libs we will need are: openexr, openimageio and >> openshadinglanguage. >> opencolorio does not need to be updated. >> >> Thanks, >> Dalai >> >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/5/17 Bastien Montagne >>> >>> I should be able to see for install_deps.sh next week… ;) >>> >>> Bastien >>> >>> On 17/05/2013 20:36, Sergey Sharybin wrote: We've discussed it in IRC today. Conclusion is: 1. Windows/OSX libs are safe for update, wouldn't lead to issues and platform maintainers could just go ahead 2. I'll update linux build environment during next week. 3. Before merge the code to trunk, we'll need to update wiki page with building instructions and update install_deps.sh. If nobody volunteers to help updating the script, i'll try to update it over next week (or two) 4. Then we're safe for merge :) Could still cause some PITA for distros maintainers tho, but eeh.. Krita will also require openexr2.0 soon so afraid the only way (apart from disabling openexr support) would be to include openexr2.0 libs to repos... On Fri, May 17, 2013 at 6:59 PM, Sergey Sharybinwrote: > Actually i'm really skeptical about such a bump. That'd introduce extra > pain building blender on linux -- seems only gentoo and arch switched > to > openexr 2.0. > > Also, some of the distros like ubuntu and fedora contains openimageio, > which is for sure linked against distro's openexr 1.6. > > This is all leads to really spaghetti changes and would rather see > updates > for build instructions and probably install dependencies script before > we'll bump openexr version required for blender. > > P.S. In any way, this will also be a PITA for distros maintainers :( > > > On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto > wrote: > >> Hi, >> >> I don't see why we would need the python part of it. >> Basically the same build settings we used for 1.71 should be used for >> 2.0 >> I >> believe. >> >> And yes other libs that depend on it will need to be recompiled: >> That means primary openimageio. But I also believe OSL and OCIO are >> needed >> (they depend on OIIO). >> [here I only built exr and oiio, but then I'm building with no >> osl/ocio] >> >> I'm not sure there is any other library (or even if ocio needs it). >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/5/15 Jürgen He
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Jurgen, I just re-confirmed here. If I build with cmake+msvc works fine. The scons+msvc release build crashes when I open the EXR. The scons+msvc debug crashes when I open Blender: http://www.pasteall.org/42743 Now scons is really powerful. For me it's the more convenient way of building blender in windows since it can be done through command-line. -- Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/1 Jürgen Herrmann : > Hi Dalai, > > The EXR libs are entirely updated to 2.0. > I am having problems with scons too but I accounted this to my absolute > inability to be friends with scons ;) > > you said the error is gone when you build with cmake so it's probably a > problem with scons because the libs are the same for both build systems. > Maybe a missing define or a wrong lib, different compiler > options/optimization? > > I just don't get to like it and it seems that scons config for windows/msvc > builds are always subject to problems. If you build blender with cmake things > work much better for a reason I don't understand. > > If I were in charge for the build systems I would drop scons completely in > favor of cmake, but I am not in charge so just forget I mentioned this. > It is much harder to adapt new build targets with scons than with cmake. The > scripts are quite complex so that new developers like me need to spend much > time on build system logic instead of having time to really do work on > blender itself. > > /Jürgen > > Am 01.06.2013 um 22:39 schrieb Dalai Felinto : > >> Hi Jurgen, >> >> Is the new EXR2.0 entirely updated for windows32 and 64 (MSVC9 - cmake >> and scons)? >> I'm a bit confused by all the sparse emails on the latest windows >> libraries and building systems updates. >> >> I'm having a segfault on windows for some builds of the multiview >> branch (building with scons if I'm not mistaken) when opening a >> multiview/multipart exr. The same does not happen in OSX. And when I >> built with cmake+msvc9+debug the error was gone. >> >> I thought the problem was in my setup, but the same happens with the >> BuilderBot multiview build: >> >> * http://builder.blender.org/download/ (multiview is the last in the list) >> * http://svn.blender.org/svnroot/bf-blender/branches/multiview/ (code >> in svn if you want to test) >> * >> https://github.com/dfelinto/blender/blob/multiview/samples/images/caminandes_new_edit.exr?raw=true >> (sample file) >> >> I will keep looking at it, but it would help to know whether it was >> supposed to work or if the libs/build setup are still work in >> progress. >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/5/17 Dalai Felinto : >>> For the records, OSX libs are already committed and working fine (thanks >>> Jens). >>> >>> For windows/linux the libs we will need are: openexr, openimageio and >>> openshadinglanguage. >>> opencolorio does not need to be updated. >>> >>> Thanks, >>> Dalai >>> >>> -- >>> blendernetwork.org/member/dalai-felinto >>> www.dalaifelinto.com >>> >>> >>> 2013/5/17 Bastien Montagne I should be able to see for install_deps.sh next week… ;) Bastien On 17/05/2013 20:36, Sergey Sharybin wrote: > We've discussed it in IRC today. Conclusion is: > > 1. Windows/OSX libs are safe for update, wouldn't lead to issues and > platform maintainers could just go ahead > 2. I'll update linux build environment during next week. > 3. Before merge the code to trunk, we'll need to update wiki page with > building instructions and update install_deps.sh. If nobody volunteers > to > help updating the script, i'll try to update it over next week (or two) > 4. Then we're safe for merge :) > > Could still cause some PITA for distros maintainers tho, but eeh.. Krita > will also require openexr2.0 soon so afraid the only way (apart from > disabling openexr support) would be to include openexr2.0 libs to > repos... > > > On Fri, May 17, 2013 at 6:59 PM, Sergey > Sharybinwrote: > >> Actually i'm really skeptical about such a bump. That'd introduce extra >> pain building blender on linux -- seems only gentoo and arch switched >> to >> openexr 2.0. >> >> Also, some of the distros like ubuntu and fedora contains openimageio, >> which is for sure linked against distro's openexr 1.6. >> >> This is all leads to really spaghetti changes and would rather see >> updates >> for build instructions and probably install dependencies script before >> we'll bump openexr version required for blender. >> >> P.S. In any way, this will also be a PITA for distros maintainers :( >> >> >> On Thu, May 16, 2013 at 1:45 AM, Dalai Felinto >> wrote: >> >>> Hi, >>> >>> I don't see why we would need the python part of it. >>> Basically the same build settings we used for 1.71 should be u
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, You can build on the command line using CMake too, but you are right from the users point if view scons is easier. But from the maintainers point if view... I hope someone will have a look at this issue soon. I really can't find an error... /Jürgen Am 02.06.2013 um 07:15 schrieb Dalai Felinto : > Hi Jurgen, > > I just re-confirmed here. If I build with cmake+msvc works fine. > > The scons+msvc release build crashes when I open the EXR. > The scons+msvc debug crashes when I open Blender: > http://www.pasteall.org/42743 > > Now scons is really powerful. For me it's the more convenient way of > building blender in windows since it can be done through command-line. > > -- > Dalai > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/6/1 Jürgen Herrmann : >> Hi Dalai, >> >> The EXR libs are entirely updated to 2.0. >> I am having problems with scons too but I accounted this to my absolute >> inability to be friends with scons ;) >> >> you said the error is gone when you build with cmake so it's probably a >> problem with scons because the libs are the same for both build systems. >> Maybe a missing define or a wrong lib, different compiler >> options/optimization? >> >> I just don't get to like it and it seems that scons config for windows/msvc >> builds are always subject to problems. If you build blender with cmake >> things work much better for a reason I don't understand. >> >> If I were in charge for the build systems I would drop scons completely in >> favor of cmake, but I am not in charge so just forget I mentioned this. >> It is much harder to adapt new build targets with scons than with cmake. The >> scripts are quite complex so that new developers like me need to spend much >> time on build system logic instead of having time to really do work on >> blender itself. >> >> /Jürgen >> >> Am 01.06.2013 um 22:39 schrieb Dalai Felinto : >> >>> Hi Jurgen, >>> >>> Is the new EXR2.0 entirely updated for windows32 and 64 (MSVC9 - cmake >>> and scons)? >>> I'm a bit confused by all the sparse emails on the latest windows >>> libraries and building systems updates. >>> >>> I'm having a segfault on windows for some builds of the multiview >>> branch (building with scons if I'm not mistaken) when opening a >>> multiview/multipart exr. The same does not happen in OSX. And when I >>> built with cmake+msvc9+debug the error was gone. >>> >>> I thought the problem was in my setup, but the same happens with the >>> BuilderBot multiview build: >>> >>> * http://builder.blender.org/download/ (multiview is the last in the list) >>> * http://svn.blender.org/svnroot/bf-blender/branches/multiview/ (code >>> in svn if you want to test) >>> * >>> https://github.com/dfelinto/blender/blob/multiview/samples/images/caminandes_new_edit.exr?raw=true >>> (sample file) >>> >>> I will keep looking at it, but it would help to know whether it was >>> supposed to work or if the libs/build setup are still work in >>> progress. >>> >>> Thanks, >>> Dalai >>> -- >>> blendernetwork.org/member/dalai-felinto >>> www.dalaifelinto.com >>> >>> >>> 2013/5/17 Dalai Felinto : For the records, OSX libs are already committed and working fine (thanks Jens). For windows/linux the libs we will need are: openexr, openimageio and openshadinglanguage. opencolorio does not need to be updated. Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/5/17 Bastien Montagne > > I should be able to see for install_deps.sh next week… ;) > > Bastien > > On 17/05/2013 20:36, Sergey Sharybin wrote: >> We've discussed it in IRC today. Conclusion is: >> >> 1. Windows/OSX libs are safe for update, wouldn't lead to issues and >> platform maintainers could just go ahead >> 2. I'll update linux build environment during next week. >> 3. Before merge the code to trunk, we'll need to update wiki page with >> building instructions and update install_deps.sh. If nobody volunteers >> to >> help updating the script, i'll try to update it over next week (or two) >> 4. Then we're safe for merge :) >> >> Could still cause some PITA for distros maintainers tho, but eeh.. Krita >> will also require openexr2.0 soon so afraid the only way (apart from >> disabling openexr support) would be to include openexr2.0 libs to >> repos... >> >> >> On Fri, May 17, 2013 at 6:59 PM, Sergey >> Sharybinwrote: >> >>> Actually i'm really skeptical about such a bump. That'd introduce extra >>> pain building blender on linux -- seems only gentoo and arch switched >>> to >>> openexr 2.0. >>> >>> Also, some of the distros like ubuntu and fedora contains openimageio, >>> which is for sure linked against distro's openexr 1.6. >>> >>> This is all leads to really spaghetti changes an
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. Please try to do a SVN update on your libs and compile again using these. These problems are strange... I will have a closer look on this tomorrow. /Jürgen Am 02.06.2013 um 20:16 schrieb Dalai Felinto : > Hi Jurgen, > I think the problem is the release library. > > Even with cmake+msvc the exr sample image fails when I build release. > And I just tested with the 1.2 oiio libraries and I still get the same > error with scons+msvc debug. > > Remember that you forgot to include a header in your first commit of > the library? I wonder if that was somehow also missing when you built > it. I don't know. > > -- > Dalai > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi again, The new OIIO libraries don't make any difference. OIIO depends on OpenEXR and not the other way around. So although that could I can't see how they would change things. I remember when you first uploaded the libraries you forgot a header file (which I'm using in the code). I wonder if it's related and the first "release" build is buggy. The ideal would be to rebuild OpenEXR for release and hope it fixes the problem. If you don't want to commit the libs without knowing they will fix the problem you can put them on blender.org ftp incoming folder. (or poke me on IRC and we can find a solution). (or checkout the svn code for multiview, it should be easy to reproduce the problem in your windows station) Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/2 Jürgen Herrmann : > Hi Dalai, > > Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. > Please try to do a SVN update on your libs and compile again using these. > These problems are strange... > I will have a closer look on this tomorrow. > > /Jürgen > > Am 02.06.2013 um 20:16 schrieb Dalai Felinto : > >> Hi Jurgen, >> I think the problem is the release library. >> >> Even with cmake+msvc the exr sample image fails when I build release. >> And I just tested with the 1.2 oiio libraries and I still get the same >> error with scons+msvc debug. >> >> Remember that you forgot to include a header in your first commit of >> the library? I wonder if that was somehow also missing when you built >> it. I don't know. >> >> -- >> Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, I can recompile the libs tomorrow. I'll contact you when I am done. I doubt that this will change anything though. The header that was missing wasn't installed by the CMake build routine it was not missing at compile time. It was just omitted by the install script. But nevertheless I'll try to recompile them for you. Otherwise we should try to report a bug to the OpenEXR devs. It could be an error in the libs. /Jürgen Am 03.06.2013 um 20:58 schrieb Dalai Felinto : > Hi again, > > The new OIIO libraries don't make any difference. OIIO depends on > OpenEXR and not the other way around. So although that could I can't > see how they would change things. > > I remember when you first uploaded the libraries you forgot a header > file (which I'm using in the code). I wonder if it's related and the > first "release" build is buggy. The ideal would be to rebuild OpenEXR > for release and hope it fixes the problem. > > If you don't want to commit the libs without knowing they will fix the > problem you can put them on blender.org ftp incoming folder. (or poke > me on IRC and we can find a solution). > > (or checkout the svn code for multiview, it should be easy to > reproduce the problem in your windows station) > > Thanks, > Dalai > > > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/6/2 Jürgen Herrmann : >> Hi Dalai, >> >> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. >> Please try to do a SVN update on your libs and compile again using these. >> These problems are strange... >> I will have a closer look on this tomorrow. >> >> /Jürgen >> >> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : >> >>> Hi Jurgen, >>> I think the problem is the release library. >>> >>> Even with cmake+msvc the exr sample image fails when I build release. >>> And I just tested with the 1.2 oiio libraries and I still get the same >>> error with scons+msvc debug. >>> >>> Remember that you forgot to include a header in your first commit of >>> the library? I wonder if that was somehow also missing when you built >>> it. I don't know. >>> >>> -- >>> Dalai > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
I found where the crash is (still no idea why it's crashing): # openexr_api.cpp::imb_load_openexr (...) (...) Mem_IStream *membuf = new Mem_IStream(mem, size); # To get there I had to build a debug build and replace the linking to: \lib\windows\openexr\lib\IlmImf.lib instead of: \lib\windows\openexr\lib\IlmImf_d.lib And it consistently breaks on Release for windows and 64, but not for Debug. Any clues on how to debug this? -- Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/3 Jürgen Herrmann : > Hi Dalai, > > I can recompile the libs tomorrow. I'll contact you when I am done. > I doubt that this will change anything though. The header that was missing > wasn't installed by the CMake build routine it was not missing at compile > time. > It was just omitted by the install script. > But nevertheless I'll try to recompile them for you. > Otherwise we should try to report a bug to the OpenEXR devs. It could be an > error in the libs. > > /Jürgen > > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : > >> Hi again, >> >> The new OIIO libraries don't make any difference. OIIO depends on >> OpenEXR and not the other way around. So although that could I can't >> see how they would change things. >> >> I remember when you first uploaded the libraries you forgot a header >> file (which I'm using in the code). I wonder if it's related and the >> first "release" build is buggy. The ideal would be to rebuild OpenEXR >> for release and hope it fixes the problem. >> >> If you don't want to commit the libs without knowing they will fix the >> problem you can put them on blender.org ftp incoming folder. (or poke >> me on IRC and we can find a solution). >> >> (or checkout the svn code for multiview, it should be easy to >> reproduce the problem in your windows station) >> >> Thanks, >> Dalai >> >> >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/6/2 Jürgen Herrmann : >>> Hi Dalai, >>> >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. >>> Please try to do a SVN update on your libs and compile again using these. >>> These problems are strange... >>> I will have a closer look on this tomorrow. >>> >>> /Jürgen >>> >>> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : >>> Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same error with scons+msvc debug. Remember that you forgot to include a header in your first commit of the library? I wonder if that was somehow also missing when you built it. I don't know. -- Dalai >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, have you tried to build a "RelWithDebInfo" Build of OpenEXR? This could help to track down the Error if the Debug Lib doesn't help. /Jürgen Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto : > I found where the crash is (still no idea why it's crashing): > > # > openexr_api.cpp::imb_load_openexr (...) > (...) > Mem_IStream *membuf = new Mem_IStream(mem, size); > # > > To get there I had to build a debug build and replace the linking to: > > \lib\windows\openexr\lib\IlmImf.lib > instead of: > \lib\windows\openexr\lib\IlmImf_d.lib > > And it consistently breaks on Release for windows and 64, but not for Debug. > Any clues on how to debug this? > > -- > Dalai > > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/6/3 Jürgen Herrmann : > > Hi Dalai, > > > > I can recompile the libs tomorrow. I'll contact you when I am done. > > I doubt that this will change anything though. The header that was missing > > wasn't installed by the CMake build routine it was not missing at compile > > time. > > It was just omitted by the install script. > > But nevertheless I'll try to recompile them for you. > > Otherwise we should try to report a bug to the OpenEXR devs. It could be an > > error in the libs. > > > > /Jürgen > > > > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : > > > >> Hi again, > >> > >> The new OIIO libraries don't make any difference. OIIO depends on > >> OpenEXR and not the other way around. So although that could I can't > >> see how they would change things. > >> > >> I remember when you first uploaded the libraries you forgot a header > >> file (which I'm using in the code). I wonder if it's related and the > >> first "release" build is buggy. The ideal would be to rebuild OpenEXR > >> for release and hope it fixes the problem. > >> > >> If you don't want to commit the libs without knowing they will fix the > >> problem you can put them on blender.org ftp incoming folder. (or poke > >> me on IRC and we can find a solution). > >> > >> (or checkout the svn code for multiview, it should be easy to > >> reproduce the problem in your windows station) > >> > >> Thanks, > >> Dalai > >> > >> > >> -- > >> blendernetwork.org/member/dalai-felinto > >> www.dalaifelinto.com > >> > >> > >> 2013/6/2 Jürgen Herrmann : > >>> Hi Dalai, > >>> > >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. > >>> Please try to do a SVN update on your libs and compile again using these. > >>> These problems are strange... > >>> I will have a closer look on this tomorrow. > >>> > >>> /Jürgen > >>> > >>> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : > >>> > Hi Jurgen, > I think the problem is the release library. > > Even with cmake+msvc the exr sample image fails when I build release. > And I just tested with the 1.2 oiio libraries and I still get the same > error with scons+msvc debug. > > Remember that you forgot to include a header in your first commit of > the library? I wonder if that was somehow also missing when you built > it. I don't know. > > -- > Dalai > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
> have you tried to build a "RelWithDebInfo" Build of OpenEXR? I tried, but if I build Blender as debug using the openexr build as Release with Debug Info it crashes at launch: http://www.pasteall.org/42864 I've been debugging via a computer I have access via RDC so it's really annoying btw. Leaving this RelWithDebInfo aside and focusing on the original problem (library working in debug but not in release), does any one have a clue on what can cause that? Namespace conflict? ...? ...? -- Dalai 2013/6/5 Jürgen Herrmann : > Hi Dalai, > > have you tried to build a "RelWithDebInfo" Build of OpenEXR? > This could help to track down the Error if the Debug Lib doesn't help. > > /Jürgen > > Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto : > >> I found where the crash is (still no idea why it's crashing): >> >> # >> openexr_api.cpp::imb_load_openexr (...) >> (...) >> Mem_IStream *membuf = new Mem_IStream(mem, size); >> # >> >> To get there I had to build a debug build and replace the linking to: >> >> \lib\windows\openexr\lib\IlmImf.lib >> instead of: >> \lib\windows\openexr\lib\IlmImf_d.lib >> >> And it consistently breaks on Release for windows and 64, but not for Debug. >> Any clues on how to debug this? >> >> -- >> Dalai >> >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/6/3 Jürgen Herrmann : >> > Hi Dalai, >> > >> > I can recompile the libs tomorrow. I'll contact you when I am done. >> > I doubt that this will change anything though. The header that was missing >> > wasn't installed by the CMake build routine it was not missing at compile >> > time. >> > It was just omitted by the install script. >> > But nevertheless I'll try to recompile them for you. >> > Otherwise we should try to report a bug to the OpenEXR devs. It could be >> > an error in the libs. >> > >> > /Jürgen >> > >> > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : >> > >> >> Hi again, >> >> >> >> The new OIIO libraries don't make any difference. OIIO depends on >> >> OpenEXR and not the other way around. So although that could I can't >> >> see how they would change things. >> >> >> >> I remember when you first uploaded the libraries you forgot a header >> >> file (which I'm using in the code). I wonder if it's related and the >> >> first "release" build is buggy. The ideal would be to rebuild OpenEXR >> >> for release and hope it fixes the problem. >> >> >> >> If you don't want to commit the libs without knowing they will fix the >> >> problem you can put them on blender.org ftp incoming folder. (or poke >> >> me on IRC and we can find a solution). >> >> >> >> (or checkout the svn code for multiview, it should be easy to >> >> reproduce the problem in your windows station) >> >> >> >> Thanks, >> >> Dalai >> >> >> >> >> >> -- >> >> blendernetwork.org/member/dalai-felinto >> >> www.dalaifelinto.com >> >> >> >> >> >> 2013/6/2 Jürgen Herrmann : >> >>> Hi Dalai, >> >>> >> >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. >> >>> Please try to do a SVN update on your libs and compile again using these. >> >>> These problems are strange... >> >>> I will have a closer look on this tomorrow. >> >>> >> >>> /Jürgen >> >>> >> >>> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : >> >>> >> Hi Jurgen, >> I think the problem is the release library. >> >> Even with cmake+msvc the exr sample image fails when I build release. >> And I just tested with the 1.2 oiio libraries and I still get the same >> error with scons+msvc debug. >> >> Remember that you forgot to include a header in your first commit of >> the library? I wonder if that was somehow also missing when you built >> it. I don't know. >> >> -- >> Dalai >> >> ___ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Update on windows bug: The crash is actually in the new code inside imb_exr_get_multiView_id() when I access the (*views).end() or even simply *i. (this is part of a string const_iterator) I tried different things (e.g., replacing the StringVector in the code by std::vector ; to take the StringVector functions and move it to outside the extern "C" part) ... nothing works. Or better, nothing make it work in release, but nothing affects debug (which still works like a charm). So ... do we really need to support Windows? *cough* As soon as I find a solution I'm seriously considering to #ifdef WIN and ifndef DEBUG and hide whatever hack we need there. And debugging with printfs is s fun. -- Dalai 2013/6/5 Dalai Felinto : >> have you tried to build a "RelWithDebInfo" Build of OpenEXR? > > I tried, but if I build Blender as debug using the openexr build as > Release with Debug Info it crashes at launch: > http://www.pasteall.org/42864 > > I've been debugging via a computer I have access via RDC so it's > really annoying btw. > > Leaving this RelWithDebInfo aside and focusing on the original problem > (library working in debug but not in release), does any one have a > clue on what can cause that? Namespace conflict? ...? ...? > > -- > Dalai > > 2013/6/5 Jürgen Herrmann : >> Hi Dalai, >> >> have you tried to build a "RelWithDebInfo" Build of OpenEXR? >> This could help to track down the Error if the Debug Lib doesn't help. >> >> /Jürgen >> >> Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto : >> >>> I found where the crash is (still no idea why it's crashing): >>> >>> # >>> openexr_api.cpp::imb_load_openexr (...) >>> (...) >>> Mem_IStream *membuf = new Mem_IStream(mem, size); >>> # >>> >>> To get there I had to build a debug build and replace the linking to: >>> >>> \lib\windows\openexr\lib\IlmImf.lib >>> instead of: >>> \lib\windows\openexr\lib\IlmImf_d.lib >>> >>> And it consistently breaks on Release for windows and 64, but not for Debug. >>> Any clues on how to debug this? >>> >>> -- >>> Dalai >>> >>> -- >>> blendernetwork.org/member/dalai-felinto >>> www.dalaifelinto.com >>> >>> >>> 2013/6/3 Jürgen Herrmann : >>> > Hi Dalai, >>> > >>> > I can recompile the libs tomorrow. I'll contact you when I am done. >>> > I doubt that this will change anything though. The header that was >>> > missing wasn't installed by the CMake build routine it was not missing at >>> > compile time. >>> > It was just omitted by the install script. >>> > But nevertheless I'll try to recompile them for you. >>> > Otherwise we should try to report a bug to the OpenEXR devs. It could be >>> > an error in the libs. >>> > >>> > /Jürgen >>> > >>> > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : >>> > >>> >> Hi again, >>> >> >>> >> The new OIIO libraries don't make any difference. OIIO depends on >>> >> OpenEXR and not the other way around. So although that could I can't >>> >> see how they would change things. >>> >> >>> >> I remember when you first uploaded the libraries you forgot a header >>> >> file (which I'm using in the code). I wonder if it's related and the >>> >> first "release" build is buggy. The ideal would be to rebuild OpenEXR >>> >> for release and hope it fixes the problem. >>> >> >>> >> If you don't want to commit the libs without knowing they will fix the >>> >> problem you can put them on blender.org ftp incoming folder. (or poke >>> >> me on IRC and we can find a solution). >>> >> >>> >> (or checkout the svn code for multiview, it should be easy to >>> >> reproduce the problem in your windows station) >>> >> >>> >> Thanks, >>> >> Dalai >>> >> >>> >> >>> >> -- >>> >> blendernetwork.org/member/dalai-felinto >>> >> www.dalaifelinto.com >>> >> >>> >> >>> >> 2013/6/2 Jürgen Herrmann : >>> >>> Hi Dalai, >>> >>> >>> >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. >>> >>> Please try to do a SVN update on your libs and compile again using >>> >>> these. >>> >>> These problems are strange... >>> >>> I will have a closer look on this tomorrow. >>> >>> >>> >>> /Jürgen >>> >>> >>> >>> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : >>> >>> >>> Hi Jurgen, >>> I think the problem is the release library. >>> >>> Even with cmake+msvc the exr sample image fails when I build release. >>> And I just tested with the 1.2 oiio libraries and I still get the same >>> error with scons+msvc debug. >>> >>> Remember that you forgot to include a header in your first commit of >>> the library? I wonder if that was somehow also missing when you built >>> it. I don't know. >>> >>> -- >>> Dalai >>> >> ___ >>> >> Bf-committers mailing list >>> >> Bf-committers@blender.org >>> >> http://lists.blender.org/mailman/listinfo/bf-committers >>> > ___ >>> > Bf-committers mailing list >>> > Bf-committers@blender.org >>> > http://lists.blender.org
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Problem solved ... Apparently Windows release wasn't happy with my vector returned from a static function. Why everyone else could take it? No idea. If anyone is curious about the fix: https://github.com/dfelinto/blender/commit/181e780aa84122db540130e4cfbdf3240cf010d9 Jurgen, the new libs seem fine, no need for rebuilds. Thanks, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/6 Dalai Felinto : > Update on windows bug: > > The crash is actually in the new code inside > imb_exr_get_multiView_id() when I access the (*views).end() or even > simply *i. (this is part of a string const_iterator) > > I tried different things (e.g., replacing the StringVector in the code > by std::vector ; to take the StringVector functions and > move it to outside the extern "C" part) ... nothing works. > > Or better, nothing make it work in release, but nothing affects debug > (which still works like a charm). > So ... do we really need to support Windows? *cough* > > As soon as I find a solution I'm seriously considering to #ifdef WIN > and ifndef DEBUG and hide whatever hack we need there. And debugging > with printfs is s fun. > -- > Dalai > > > 2013/6/5 Dalai Felinto : >>> have you tried to build a "RelWithDebInfo" Build of OpenEXR? >> >> I tried, but if I build Blender as debug using the openexr build as >> Release with Debug Info it crashes at launch: >> http://www.pasteall.org/42864 >> >> I've been debugging via a computer I have access via RDC so it's >> really annoying btw. >> >> Leaving this RelWithDebInfo aside and focusing on the original problem >> (library working in debug but not in release), does any one have a >> clue on what can cause that? Namespace conflict? ...? ...? >> >> -- >> Dalai >> >> 2013/6/5 Jürgen Herrmann : >>> Hi Dalai, >>> >>> have you tried to build a "RelWithDebInfo" Build of OpenEXR? >>> This could help to track down the Error if the Debug Lib doesn't help. >>> >>> /Jürgen >>> >>> Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto : >>> I found where the crash is (still no idea why it's crashing): # openexr_api.cpp::imb_load_openexr (...) (...) Mem_IStream *membuf = new Mem_IStream(mem, size); # To get there I had to build a debug build and replace the linking to: \lib\windows\openexr\lib\IlmImf.lib instead of: \lib\windows\openexr\lib\IlmImf_d.lib And it consistently breaks on Release for windows and 64, but not for Debug. Any clues on how to debug this? -- Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/3 Jürgen Herrmann : > Hi Dalai, > > I can recompile the libs tomorrow. I'll contact you when I am done. > I doubt that this will change anything though. The header that was > missing wasn't installed by the CMake build routine it was not missing > at compile time. > It was just omitted by the install script. > But nevertheless I'll try to recompile them for you. > Otherwise we should try to report a bug to the OpenEXR devs. It could be > an error in the libs. > > /Jürgen > > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : > >> Hi again, >> >> The new OIIO libraries don't make any difference. OIIO depends on >> OpenEXR and not the other way around. So although that could I can't >> see how they would change things. >> >> I remember when you first uploaded the libraries you forgot a header >> file (which I'm using in the code). I wonder if it's related and the >> first "release" build is buggy. The ideal would be to rebuild OpenEXR >> for release and hope it fixes the problem. >> >> If you don't want to commit the libs without knowing they will fix the >> problem you can put them on blender.org ftp incoming folder. (or poke >> me on IRC and we can find a solution). >> >> (or checkout the svn code for multiview, it should be easy to >> reproduce the problem in your windows station) >> >> Thanks, >> Dalai >> >> >> -- >> blendernetwork.org/member/dalai-felinto >> www.dalaifelinto.com >> >> >> 2013/6/2 Jürgen Herrmann : >>> Hi Dalai, >>> >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. >>> Please try to do a SVN update on your libs and compile again using >>> these. >>> These problems are strange... >>> I will have a closer look on this tomorrow. >>> >>> /Jürgen >>> >>> Am 02.06.2013 um 20:16 schrieb Dalai Felinto : >>> Hi Jurgen, I think the problem is the release library. Even with cmake+msvc the exr sample image fails when I build release. And I just tested with the 1.2 oiio libraries and I still get the same er
Re: [Bf-committers] platform maintainers: request to update exr lib to 2.0
Hi Dalai, congrats on finding this nasty thing ;) MSVC indeed is a bit picky about casting static return variables to pointers. /Jürgen Am 07. Juni 2013 um 09:54 schrieb Dalai Felinto : > Problem solved ... > > Apparently Windows release wasn't happy with my vector > returned from a static function. > Why everyone else could take it? No idea. > > If anyone is curious about the fix: > https://github.com/dfelinto/blender/commit/181e780aa84122db540130e4cfbdf3240cf010d9 > > Jurgen, the new libs seem fine, no need for rebuilds. > Thanks, > > Dalai > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/6/6 Dalai Felinto : > > Update on windows bug: > > > > The crash is actually in the new code inside > > imb_exr_get_multiView_id() when I access the (*views).end() or even > > simply *i. (this is part of a string const_iterator) > > > > I tried different things (e.g., replacing the StringVector in the code > > by std::vector ; to take the StringVector functions and > > move it to outside the extern "C" part) ... nothing works. > > > > Or better, nothing make it work in release, but nothing affects debug > > (which still works like a charm). > > So ... do we really need to support Windows? *cough* > > > > As soon as I find a solution I'm seriously considering to #ifdef WIN > > and ifndef DEBUG and hide whatever hack we need there. And debugging > > with printfs is s fun. > > -- > > Dalai > > > > > > 2013/6/5 Dalai Felinto : > >>> have you tried to build a "RelWithDebInfo" Build of OpenEXR? > >> > >> I tried, but if I build Blender as debug using the openexr build as > >> Release with Debug Info it crashes at launch: > >> http://www.pasteall.org/42864 > >> > >> I've been debugging via a computer I have access via RDC so it's > >> really annoying btw. > >> > >> Leaving this RelWithDebInfo aside and focusing on the original problem > >> (library working in debug but not in release), does any one have a > >> clue on what can cause that? Namespace conflict? ...? ...? > >> > >> -- > >> Dalai > >> > >> 2013/6/5 Jürgen Herrmann : > >>> Hi Dalai, > >>> > >>> have you tried to build a "RelWithDebInfo" Build of OpenEXR? > >>> This could help to track down the Error if the Debug Lib doesn't help. > >>> > >>> /Jürgen > >>> > >>> Am 05. Juni 2013 um 10:40 schrieb Dalai Felinto : > >>> > I found where the crash is (still no idea why it's crashing): > > # > openexr_api.cpp::imb_load_openexr (...) > (...) > Mem_IStream *membuf = new Mem_IStream(mem, size); > # > > To get there I had to build a debug build and replace the linking to: > > \lib\windows\openexr\lib\IlmImf.lib > instead of: > \lib\windows\openexr\lib\IlmImf_d.lib > > And it consistently breaks on Release for windows and 64, but not for > Debug. > Any clues on how to debug this? > > -- > Dalai > > -- > blendernetwork.org/member/dalai-felinto > www.dalaifelinto.com > > > 2013/6/3 Jürgen Herrmann : > > Hi Dalai, > > > > I can recompile the libs tomorrow. I'll contact you when I am done. > > I doubt that this will change anything though. The header that was > > missing wasn't installed by the CMake build routine it was not missing > > at compile time. > > It was just omitted by the install script. > > But nevertheless I'll try to recompile them for you. > > Otherwise we should try to report a bug to the OpenEXR devs. It could > > be an error in the libs. > > > > /Jürgen > > > > Am 03.06.2013 um 20:58 schrieb Dalai Felinto : > > > >> Hi again, > >> > >> The new OIIO libraries don't make any difference. OIIO depends on > >> OpenEXR and not the other way around. So although that could I can't > >> see how they would change things. > >> > >> I remember when you first uploaded the libraries you forgot a header > >> file (which I'm using in the code). I wonder if it's related and the > >> first "release" build is buggy. The ideal would be to rebuild OpenEXR > >> for release and hope it fixes the problem. > >> > >> If you don't want to commit the libs without knowing they will fix the > >> problem you can put them on blender.org ftp incoming folder. (or poke > >> me on IRC and we can find a solution). > >> > >> (or checkout the svn code for multiview, it should be easy to > >> reproduce the problem in your windows station) > >> > >> Thanks, > >> Dalai > >> > >> > >> -- > >> blendernetwork.org/member/dalai-felinto > >> www.dalaifelinto.com > >> > >> > >> 2013/6/2 Jürgen Herrmann : > >>> Hi Dalai, > >>> > >>> Thomas Dinges asked me to downgrade OIIO to 1.1.11 just today. > >>> Please try to do a SVN update on your libs and compile again using
