Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Matteo F. Vescovi]

Hi!

On 2016-01-13 at 18:29 (CET), Larry Gritz wrote:
> I don't understand it completely, but I have a theory.
> 
> Can you try an experiment for me?
> 
> In imagecache.cpp, line 2113, you'll see ImageCache::check:max_mem().
> Please add the following at the very start of the function body, immediately 
> BEFORE the DASSERT of line 2113:
> 
> #ifndef NDEBUG
> if (m_mem_used >= (long long)m_max_memory_bytes*10) {
> std::cout << "Huh? m_mem_used=" << m_mem_used
>   << " max_mememory_bytes=" << m_max_memory_bytes << "\n";
> std::cout << " 10*max_mememory_bytes=" << (long 
> long)m_max_memory_bytes*10 << "\n";
> std::cout << "Size of long long is " << sizeof(long long) << "\n";
> std::cout << "Size of atomic_ll is " << sizeof(atomic_ll) << "\n";
> }
> #endif
> 
> And then let's try again and see what prints. 

http://debomatic-i386.debian.net/distribution#experimental/openimageio/1.6.9~dfsg0-2/buildlog

Thanks for your effort in fixing this.

Cheers.


-- 
Matteo F. Vescovi
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Matteo F. Vescovi]

Hi!

On Tue, Jan 12, 2016 at 9:26 AM Matteo F. Vescovi 
wrote:

> I guess I'm gonna try it later today (CET), since I'm at work place now.
> Feel free to have some sleep now ;-)
> I'll let you know if it works when you wake up.
>

So, it builds... almost.

It fails on the final stage, while creating the images, it seems.

Please a look at [1] and tell me if you see something suspicious there.

Cheers.

mfv


[1]
http://debomatic-i386.debian.net/distribution#experimental/openimageio/1.6.9~dfsg0-2/buildlog
-- 

Matteo F. Vescovi
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

I don't understand it completely, but I have a theory.

Can you try an experiment for me?

In imagecache.cpp, line 2113, you'll see ImageCache::check:max_mem().
Please add the following at the very start of the function body, immediately 
BEFORE the DASSERT of line 2113:

#ifndef NDEBUG
if (m_mem_used >= (long long)m_max_memory_bytes*10) {
std::cout << "Huh? m_mem_used=" << m_mem_used
  << " max_mememory_bytes=" << m_max_memory_bytes << "\n";
std::cout << " 10*max_mememory_bytes=" << (long 
long)m_max_memory_bytes*10 << "\n";
std::cout << "Size of long long is " << sizeof(long long) << "\n";
std::cout << "Size of atomic_ll is " << sizeof(atomic_ll) << "\n";
}
#endif

And then let's try again and see what prints. 



> On Jan 13, 2016, at 1:25 AM, Matteo F. Vescovi  wrote:
> 
> Hi!
> 
> On Tue, Jan 12, 2016 at 9:26 AM Matteo F. Vescovi  > wrote:
> I guess I'm gonna try it later today (CET), since I'm at work place now.
> Feel free to have some sleep now ;-)
> I'll let you know if it works when you wake up.
> 
> So, it builds... almost.
> 
> It fails on the final stage, while creating the images, it seems.
> 
> Please a look at [1] and tell me if you see something suspicious there.
> 
> Cheers.
> 
> mfv
> 
> 
> [1] 
> http://debomatic-i386.debian.net/distribution#experimental/openimageio/1.6.9~dfsg0-2/buildlog
>  
> 
> -- 
> Matteo F. Vescovi
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

I think I understand what's going wrong.

How about this: https://github.com/OpenImageIO/oiio/pull/1315

That's a fix against 1.6. Can you give that a try?


> On Jan 11, 2016, at 11:29 PM, Matteo F. Vescovi  wrote:
> 
> Hi!
> 
> On Mon, Jan 11, 2016 at 2:52 PM, Matteo F. Vescovi  
> wrote:
>> Hi!
>> 
>> On Mon, Jan 11, 2016 at 5:54 AM, Larry Gritz  wrote:
>>> * Almost always, the Debian build breaks are "warnings" that are treated as 
>>> errors. You may wish to consider compiling with STOP_ON_WARNING=0 as 
>>> standard practice, and only every once in a while compile without it and 
>>> report back to us any errors you encounter -- OR, compile the usual way by 
>>> default but know that if it fails, try again with STOP_ON_WARNING=0 and use 
>>> that build if it succeeds. In any case, if STOP_ON_WARNING=0 succeeds, you 
>>> should go with that build. If you send us the logs, we can address the 
>>> warning as promptly as we can, but it should never hold up your updating 
>>> the package. The warnings are almost always harmless.
>> 
>> OK, gonna use this as a standard, then.
> 
> So I did it... and fyi it builds fine on amd64 architecture but fails
> on i386, as follows:
> 
> [ 78%] Linking CXX executable imagecache_test
> cd "/«PKGBUILDDIR»/build/src/libOpenImageIO" && /usr/bin/cmake -E
> cmake_link_script CMakeFiles/imagecache_test.dir/link.txt --verbose=1
> /usr/bin/c++   -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> -Wl,-z,relro -latomic
> CMakeFiles/imagecache_test.dir/imagecache_test.cpp.o  -o
> imagecache_test -rdynamic libOpenImageIO.so.1.6.9 -lboost_filesystem
> -lboost_regex -lboost_system -lboost_thread -lpthread -lrt -ldl -lHalf
> -lIex -lImath -lIlmThread -lpthread -lOpenColorIO -lopencv_core
> -lopencv_highgui -lfreetype -lpng -lz -ltiff -ljpeg -lopenjpeg -lwebp
> -lz -ltiff -ljpeg -lopenjpeg -lwebp -lIlmImf -lgif -lraw_r -lHalf
> -lIex -lImath -lIlmThread -lpthread
> -Wl,-rpath,"/«PKGBUILDDIR»/build/src/libOpenImageIO"
> libOpenImageIO.so.1.6.9: undefined reference to
> `OpenImageIO::v1_6::CSHA1::Update(unsigned char const*, unsigned
> long)'
> collect2: error: ld returned 1 exit status
> src/libOpenImageIO/CMakeFiles/imagecache_test.dir/build.make:127:
> recipe for target 'src/libOpenImageIO/imagecache_test' failed
> make[4]: *** [src/libOpenImageIO/imagecache_test] Error 1
> make[4]: Leaving directory '/«PKGBUILDDIR»/build'
> CMakeFiles/Makefile2:1628: recipe for target
> 'src/libOpenImageIO/CMakeFiles/imagecache_test.dir/all' failed
> make[3]: *** [src/libOpenImageIO/CMakeFiles/imagecache_test.dir/all] Error 2
> make[3]: *** Waiting for unfinished jobs
> 
> It's failing also on another architecture, at least.
> 
> Gotta check what's wrong there.
> 
> Cheers.
> 
> -- 
> Matteo F. Vescovi
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Kevin Wheatley]

For those worried about binary size, under Linux you can do something
like the following, which builds with the '-g' flag thus has all the
debug information in the object, then extracts the debug info to a
separate file and then strips it from the main object and adds back a
reference to the debug info. That way you have your cake and eat it,
under normal usage you only load the main executable, but if you
attach gdb or similar debugger it will use the debuglink reference to
find the debug symbols. I've got cases where the shared object is like
20K and the separate debug info is 160K, but also cases where is only
shaves of 25% of the combined size depending on situation.

Kevin

In the following case it assumes the debug symbols live alongside the
binary (shared object in this case), thus

foo.so
foo.so.debuginfo

Something like the following (Make syntax)

DEBUGINFOEXT = .debuginfo
CXXFLAGS = -g

%.o: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

%.so: %.o
$(CXX) $(LDFLAGS) -shared -o $@ $< $(LDLIBS)
objcopy --only-keep-debug $@ $@${DEBUGINFOEXT}
strip --strip-debug --strip-unneeded $@
objcopy --add-gnu-debuglink=$@${DEBUGINFOEXT} $@
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

That sounds to me like a small price to pay in order to always have a clean 
stack trace and be able to profile without a recompile.

We can add a build-time flag to force not using -g, for those who really don't 
want to pay for the 70M. 

Does that sound reasonable? Or do you think the default should be the other way 
around? (Keep optimized build as it is, eliminate separate "profile" mode, and 
simply have a build-time flag to turn on -g?)



> On Jan 11, 2016, at 2:12 PM, Thiago Ize  wrote:
> 
> My understanding is the only issue is the library takes up more space on 
> disk.  On my mac with OIIO 1.5, it increases the libOpenImageIO.a from 25MB 
> to 92MB.
> 
> On Mon, Jan 11, 2016 at 12:28 PM, Larry Gritz  > wrote:
> Is there a down-side to using -g to include the symbols for all optimized 
> builds? Does it make the library or binaries dramatically bigger? (You can 
> always strip binaries to fix that.)
> 
> There are no secrecy- or security-based reasons to avoid symbols, as you 
> might for a commercial product.
> 
> Maybe eliminate profile mode entirely, have the optimized build use -g by 
> default, but have a build-time option to not embed the symbols, for anybody 
> who really needs to squeeze out that last bit of storage?
> 
> 
>> On Jan 11, 2016, at 11:19 AM, Thiago Ize > > wrote:
>> 
>> I think profile mode should be the same as release mode but with -g added 
>> in, otherwise it's possible I'll waste time trying to optimize a hotspot in 
>> -O2 that doesn't exist in the -O3 build.  Furthermore, this would make it 
>> simple for the fedora/debian/etc... builds to build with symbols -- they 
>> just choose profile mode and be done with it.
>> 
>> On Mon, Jan 11, 2016 at 12:11 PM, Larry Gritz > > wrote:
>> There is nothing sacred about the current profile mode. If a different set 
>> of flags would be more useful, let's change it.
>> 
>> -- lg
>> 
>> 
>> > On Jan 11, 2016, at 7:26 AM, Thiago Ize > > > wrote:
>> >
>> > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" 
>> > (-O0, -g).  If you're actually building in debug mode and then stripping 
>> > symbols, all your users are now getting a really slow and crappy OIIO 
>> > without any optimizations.  What you want is to just add the debug symbols 
>> >  (-g) to the release mode.  Ideally the profile mode would do this for 
>> > you, but I think the profile mode in OIIO uses different optimization 
>> > settings, which makes it kind of useless (you want to profile the real 
>> > code made with -O3, not the -O2 code).
>> >
>> >
> 
> --
> Larry Gritz
> l...@larrygritz.com 
> 
> 
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org 
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
> 
> 
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Malcolm Humphreys]

I think it should be the other way around as I expect production builds to be 
smallest possible to speed up any IO when software is installed on network 
storage.

It’s a bit like saying your expecting the software to crash so make the library 
3x bigger.. OIIO is pretty stable in most places I see it used and only is 
unstable with any of the bleeding edge dev.

I do expect the debug build to be as fast as the production one but just with 
all the symbols so a trace makes some sense.

.malcolm

> On 11 Jan 2016, at 10:25 pm, Larry Gritz  wrote:
> 
> That sounds to me like a small price to pay in order to always have a clean 
> stack trace and be able to profile without a recompile.
> 
> We can add a build-time flag to force not using -g, for those who really 
> don't want to pay for the 70M. 
> 
> Does that sound reasonable? Or do you think the default should be the other 
> way around? (Keep optimized build as it is, eliminate separate "profile" 
> mode, and simply have a build-time flag to turn on -g?)
> 
> 
> 
>> On Jan 11, 2016, at 2:12 PM, Thiago Ize > > wrote:
>> 
>> My understanding is the only issue is the library takes up more space on 
>> disk.  On my mac with OIIO 1.5, it increases the libOpenImageIO.a from 25MB 
>> to 92MB.
>> 
>> On Mon, Jan 11, 2016 at 12:28 PM, Larry Gritz > > wrote:
>> Is there a down-side to using -g to include the symbols for all optimized 
>> builds? Does it make the library or binaries dramatically bigger? (You can 
>> always strip binaries to fix that.)
>> 
>> There are no secrecy- or security-based reasons to avoid symbols, as you 
>> might for a commercial product.
>> 
>> Maybe eliminate profile mode entirely, have the optimized build use -g by 
>> default, but have a build-time option to not embed the symbols, for anybody 
>> who really needs to squeeze out that last bit of storage?
>> 
>> 
>>> On Jan 11, 2016, at 11:19 AM, Thiago Ize >> > wrote:
>>> 
>>> I think profile mode should be the same as release mode but with -g added 
>>> in, otherwise it's possible I'll waste time trying to optimize a hotspot in 
>>> -O2 that doesn't exist in the -O3 build.  Furthermore, this would make it 
>>> simple for the fedora/debian/etc... builds to build with symbols -- they 
>>> just choose profile mode and be done with it.
>>> 
>>> On Mon, Jan 11, 2016 at 12:11 PM, Larry Gritz >> > wrote:
>>> There is nothing sacred about the current profile mode. If a different set 
>>> of flags would be more useful, let's change it.
>>> 
>>> -- lg
>>> 
>>> 
>>> > On Jan 11, 2016, at 7:26 AM, Thiago Ize >> > > wrote:
>>> >
>>> > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" 
>>> > (-O0, -g).  If you're actually building in debug mode and then stripping 
>>> > symbols, all your users are now getting a really slow and crappy OIIO 
>>> > without any optimizations.  What you want is to just add the debug 
>>> > symbols  (-g) to the release mode.  Ideally the profile mode would do 
>>> > this for you, but I think the profile mode in OIIO uses different 
>>> > optimization settings, which makes it kind of useless (you want to 
>>> > profile the real code made with -O3, not the -O2 code).
>>> >
>>> >
>> 
>> --
>> Larry Gritz
>> l...@larrygritz.com 
>> 
>> 
>> 
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org 
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
>> 
>> 
>> 
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org 
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> --
> Larry Gritz
> l...@larrygritz.com 
> 
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Matteo F. Vescovi]

Hi!

On Mon, Jan 11, 2016 at 2:52 PM, Matteo F. Vescovi  wrote:
> Hi!
>
> On Mon, Jan 11, 2016 at 5:54 AM, Larry Gritz  wrote:
>> * Almost always, the Debian build breaks are "warnings" that are treated as 
>> errors. You may wish to consider compiling with STOP_ON_WARNING=0 as 
>> standard practice, and only every once in a while compile without it and 
>> report back to us any errors you encounter -- OR, compile the usual way by 
>> default but know that if it fails, try again with STOP_ON_WARNING=0 and use 
>> that build if it succeeds. In any case, if STOP_ON_WARNING=0 succeeds, you 
>> should go with that build. If you send us the logs, we can address the 
>> warning as promptly as we can, but it should never hold up your updating the 
>> package. The warnings are almost always harmless.
>
> OK, gonna use this as a standard, then.

So I did it... and fyi it builds fine on amd64 architecture but fails
on i386, as follows:

[ 78%] Linking CXX executable imagecache_test
cd "/«PKGBUILDDIR»/build/src/libOpenImageIO" && /usr/bin/cmake -E
cmake_link_script CMakeFiles/imagecache_test.dir/link.txt --verbose=1
/usr/bin/c++   -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-z,relro -latomic
CMakeFiles/imagecache_test.dir/imagecache_test.cpp.o  -o
imagecache_test -rdynamic libOpenImageIO.so.1.6.9 -lboost_filesystem
-lboost_regex -lboost_system -lboost_thread -lpthread -lrt -ldl -lHalf
-lIex -lImath -lIlmThread -lpthread -lOpenColorIO -lopencv_core
-lopencv_highgui -lfreetype -lpng -lz -ltiff -ljpeg -lopenjpeg -lwebp
-lz -ltiff -ljpeg -lopenjpeg -lwebp -lIlmImf -lgif -lraw_r -lHalf
-lIex -lImath -lIlmThread -lpthread
-Wl,-rpath,"/«PKGBUILDDIR»/build/src/libOpenImageIO"
libOpenImageIO.so.1.6.9: undefined reference to
`OpenImageIO::v1_6::CSHA1::Update(unsigned char const*, unsigned
long)'
collect2: error: ld returned 1 exit status
src/libOpenImageIO/CMakeFiles/imagecache_test.dir/build.make:127:
recipe for target 'src/libOpenImageIO/imagecache_test' failed
make[4]: *** [src/libOpenImageIO/imagecache_test] Error 1
make[4]: Leaving directory '/«PKGBUILDDIR»/build'
CMakeFiles/Makefile2:1628: recipe for target
'src/libOpenImageIO/CMakeFiles/imagecache_test.dir/all' failed
make[3]: *** [src/libOpenImageIO/CMakeFiles/imagecache_test.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs

It's failing also on another architecture, at least.

Gotta check what's wrong there.

Cheers.

-- 
Matteo F. Vescovi
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Richard Shaw]

On Mon, Jan 11, 2016 at 9:26 AM, Thiago Ize  wrote:

> There's a difference between symbols (-g), -DNDEBUG, and "debug mode"
> (-O0, -g).  If you're actually building in debug mode and then stripping
> symbols, all your users are now getting a really slow and crappy OIIO
> without any optimizations.  What you want is to just add the debug symbols
> (-g) to the release mode.  Ideally the profile mode would do this for you,
> but I think the profile mode in OIIO uses different optimization settings,
> which makes it kind of useless (you want to profile the real code made with
> -O3, not the -O2 code).
>

Ahh, I didn't distinguish there. Standard build flags for Fedora include -g
-O2 (not -O3).

Thanks,
Richard
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Thiago Ize]

There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0,
-g).  If you're actually building in debug mode and then stripping symbols,
all your users are now getting a really slow and crappy OIIO without any
optimizations.  What you want is to just add the debug symbols  (-g) to the
release mode.  Ideally the profile mode would do this for you, but I think
the profile mode in OIIO uses different optimization settings, which makes
it kind of useless (you want to profile the real code made with -O3, not
the -O2 code).

On Mon, Jan 11, 2016 at 6:55 AM, Richard Shaw  wrote:

> On Sun, Jan 10, 2016 at 10:54 PM, Larry Gritz  wrote:
>
>> * This particular problem (and some others we've had for your builds,
>> IIRC) are in a DASSERT, and thus only a build break for DEBUG builds. I
>> think you should seriously consider the merits of building in DEBUG mode.
>> Why is it helpful to your users? It seems to me that anyone who needs to
>> debug *into* OIIO can probably build from source, and for everybody else
>> it's probably a distraction and they would prefer only an optimized build?
>> Is there a good reason to provide a debug build? Is that standard for all
>> libraries?
>
>
> I can't speak for Debian but for Fedora debug builds are required.
> Rpmbuild strips all the debug info into a separate debuginfo subpackage
> which can be installed on demand to get more detailed information after a
> crash/segfault.
>
> That's why the bugzilla reports have so much detail in them.
>
> Thanks,
> Richard
>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Thiago Ize]

So you'd want to also add in -DNDEBUG.  There's a bunch of other flags that
OIIO sets which you probably would also want to include.

On Mon, Jan 11, 2016 at 9:29 AM, Richard Shaw  wrote:

> On Mon, Jan 11, 2016 at 9:26 AM, Thiago Ize  wrote:
>
>> There's a difference between symbols (-g), -DNDEBUG, and "debug mode"
>> (-O0, -g).  If you're actually building in debug mode and then stripping
>> symbols, all your users are now getting a really slow and crappy OIIO
>> without any optimizations.  What you want is to just add the debug symbols
>> (-g) to the release mode.  Ideally the profile mode would do this for you,
>> but I think the profile mode in OIIO uses different optimization settings,
>> which makes it kind of useless (you want to profile the real code made with
>> -O3, not the -O2 code).
>>
>
> Ahh, I didn't distinguish there. Standard build flags for Fedora include
> -g -O2 (not -O3).
>
> Thanks,
> Richard
>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

The build is still ultimately using cmake, no? That should still create an 
optimized build by default, including -DNDEBUG.

I agree that if policy is simply to have symbols, we should just make an option 
to add -g, not make a full DEBUG build. A true debug build absolutely kills 
performance.



> On Jan 11, 2016, at 8:33 AM, Thiago Ize  wrote:
> 
> So you'd want to also add in -DNDEBUG.  There's a bunch of other flags that 
> OIIO sets which you probably would also want to include.
> 
> On Mon, Jan 11, 2016 at 9:29 AM, Richard Shaw  > wrote:
> On Mon, Jan 11, 2016 at 9:26 AM, Thiago Ize  > wrote:
> There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0, 
> -g).  If you're actually building in debug mode and then stripping symbols, 
> all your users are now getting a really slow and crappy OIIO without any 
> optimizations.  What you want is to just add the debug symbols  (-g) to the 
> release mode.  Ideally the profile mode would do this for you, but I think 
> the profile mode in OIIO uses different optimization settings, which makes it 
> kind of useless (you want to profile the real code made with -O3, not the -O2 
> code).
> 
> Ahh, I didn't distinguish there. Standard build flags for Fedora include -g 
> -O2 (not -O3).
> 
> Thanks,
> Richard 
> 
> 

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Thiago Ize]

I think profile mode should be the same as release mode but with -g added
in, otherwise it's possible I'll waste time trying to optimize a hotspot in
-O2 that doesn't exist in the -O3 build.  Furthermore, this would make it
simple for the fedora/debian/etc... builds to build with symbols -- they
just choose profile mode and be done with it.

On Mon, Jan 11, 2016 at 12:11 PM, Larry Gritz  wrote:

> There is nothing sacred about the current profile mode. If a different set
> of flags would be more useful, let's change it.
>
> -- lg
>
>
> > On Jan 11, 2016, at 7:26 AM, Thiago Ize  wrote:
> >
> > There's a difference between symbols (-g), -DNDEBUG, and "debug mode"
> (-O0, -g).  If you're actually building in debug mode and then stripping
> symbols, all your users are now getting a really slow and crappy OIIO
> without any optimizations.  What you want is to just add the debug symbols
> (-g) to the release mode.  Ideally the profile mode would do this for you,
> but I think the profile mode in OIIO uses different optimization settings,
> which makes it kind of useless (you want to profile the real code made with
> -O3, not the -O2 code).
> >
> >
>
> --
> Larry Gritz
> l...@larrygritz.com
>
>
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

Is there a down-side to using -g to include the symbols for all optimized 
builds? Does it make the library or binaries dramatically bigger? (You can 
always strip binaries to fix that.)

There are no secrecy- or security-based reasons to avoid symbols, as you might 
for a commercial product.

Maybe eliminate profile mode entirely, have the optimized build use -g by 
default, but have a build-time option to not embed the symbols, for anybody who 
really needs to squeeze out that last bit of storage?


> On Jan 11, 2016, at 11:19 AM, Thiago Ize  wrote:
> 
> I think profile mode should be the same as release mode but with -g added in, 
> otherwise it's possible I'll waste time trying to optimize a hotspot in -O2 
> that doesn't exist in the -O3 build.  Furthermore, this would make it simple 
> for the fedora/debian/etc... builds to build with symbols -- they just choose 
> profile mode and be done with it.
> 
> On Mon, Jan 11, 2016 at 12:11 PM, Larry Gritz  > wrote:
> There is nothing sacred about the current profile mode. If a different set of 
> flags would be more useful, let's change it.
> 
> -- lg
> 
> 
> > On Jan 11, 2016, at 7:26 AM, Thiago Ize  > > wrote:
> >
> > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0, 
> > -g).  If you're actually building in debug mode and then stripping symbols, 
> > all your users are now getting a really slow and crappy OIIO without any 
> > optimizations.  What you want is to just add the debug symbols  (-g) to the 
> > release mode.  Ideally the profile mode would do this for you, but I think 
> > the profile mode in OIIO uses different optimization settings, which makes 
> > it kind of useless (you want to profile the real code made with -O3, not 
> > the -O2 code).
> >
> >

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

There is nothing sacred about the current profile mode. If a different set of 
flags would be more useful, let's change it.

-- lg


> On Jan 11, 2016, at 7:26 AM, Thiago Ize  wrote:
> 
> There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0, 
> -g).  If you're actually building in debug mode and then stripping symbols, 
> all your users are now getting a really slow and crappy OIIO without any 
> optimizations.  What you want is to just add the debug symbols  (-g) to the 
> release mode.  Ideally the profile mode would do this for you, but I think 
> the profile mode in OIIO uses different optimization settings, which makes it 
> kind of useless (you want to profile the real code made with -O3, not the -O2 
> code).
> 
> 

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

For the Fedora debug builds, is it merely required to have -g symbols (so you 
can tell which OIIO functions are being called or get a readable stack trace in 
case of a crash), or do you need full line-by-line symbol-by-symbol debugging 
ability WITHIN the OIIO library?


> On Jan 11, 2016, at 5:55 AM, Richard Shaw  wrote:
> 
> On Sun, Jan 10, 2016 at 10:54 PM, Larry Gritz  > wrote:
> * This particular problem (and some others we've had for your builds, IIRC) 
> are in a DASSERT, and thus only a build break for DEBUG builds. I think you 
> should seriously consider the merits of building in DEBUG mode. Why is it 
> helpful to your users? It seems to me that anyone who needs to debug *into* 
> OIIO can probably build from source, and for everybody else it's probably a 
> distraction and they would prefer only an optimized build? Is there a good 
> reason to provide a debug build? Is that standard for all libraries?
> 
> I can't speak for Debian but for Fedora debug builds are required. Rpmbuild 
> strips all the debug info into a separate debuginfo subpackage which can be 
> installed on demand to get more detailed information after a crash/segfault. 
> 
> That's why the bugzilla reports have so much detail in them. 
> 
> Thanks,
> Richard 
> 

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Larry Gritz]

Based on those logs, I think the specific problem has already been fixed.

Can you try the current "top" of RB-1.6 to verify? If it works, I'll tag the 
current top and declare a new release if you need.

We just recently started having the Travis-CI tests include a debug build (and 
that's why it is already fixed), so hopefully this kind of problem will be more 
rare in the future.

So, how can we cut down even more to reduce the chances of breaking your builds 
(and then us having to track it down and cut new releases just to fix it)? 
There are a few things to consider:

* Almost always, the Debian build breaks are "warnings" that are treated as 
errors. You may wish to consider compiling with STOP_ON_WARNING=0 as standard 
practice, and only every once in a while compile without it and report back to 
us any errors you encounter -- OR, compile the usual way by default but know 
that if it fails, try again with STOP_ON_WARNING=0 and use that build if it 
succeeds. In any case, if STOP_ON_WARNING=0 succeeds, you should go with that 
build. If you send us the logs, we can address the warning as promptly as we 
can, but it should never hold up your updating the package. The warnings are 
almost always harmless.

* This particular problem (and some others we've had for your builds, IIRC) are 
in a DASSERT, and thus only a build break for DEBUG builds. I think you should 
seriously consider the merits of building in DEBUG mode. Why is it helpful to 
your users? It seems to me that anyone who needs to debug *into* OIIO can 
probably build from source, and for everybody else it's probably a distraction 
and they would prefer only an optimized build? Is there a good reason to 
provide a debug build? Is that standard for all libraries?

* Is there a way you can do a nightly (or less frequently, but periodic) builds 
that can catch these little breakages as soon as they go in, rather than only 
after we've tagged a release?


> On Jan 8, 2016, at 12:22 AM, Matteo F. Vescovi  wrote:
> 
> Hi!
> 
> On Fri, Jan 8, 2016 at 8:55 AM, Ghislain Vaillant  wrote:
>> Works if you disable error on warnings with -DSTOP_ON_WARNING=OFF. I believe
>> I mentioned this fix in the private email exchange we had yesterday.
> 
> Well, it sounds to me like a workaround more than a fix and I didn't
> mention in my reply to your private mail because I was preferring
> finding a better solution, that is asking the upstream
> developer/maintainer in this case ;-)
> 
> Let's wait and hear something from Larry.
> 
> Cheers.
> 
> -- 
> Matteo F. Vescovi

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Matteo F. Vescovi]

Hi!

On Fri, Jan 8, 2016 at 8:55 AM, Ghislain Vaillant  wrote:
> Works if you disable error on warnings with -DSTOP_ON_WARNING=OFF. I believe
> I mentioned this fix in the private email exchange we had yesterday.

Well, it sounds to me like a workaround more than a fix and I didn't
mention in my reply to your private mail because I was preferring
finding a better solution, that is asking the upstream
developer/maintainer in this case ;-)

Let's wait and hear something from Larry.

Cheers.

-- 
Matteo F. Vescovi
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org