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,
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
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
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.
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
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
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
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
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
>
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
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:
>
>>
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.
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
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.
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,
>
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
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
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
18 matches
Mail list logo