Any way to workaround Optlink crash?

[Tom S]

Denis Koroskin wrote:
> I was refactoring the following line of code:
> 
> foo(rand() % 256); -> foo(0);
> 
> and that causes Optlink to crash now. Any reason why it does so? 
> 
> That particular file is just 157 lines long, but the whole project is quite big, although there are no large files. The biggest one is ~140K, it's from win32 bindings project (only defines a bunch of constants, and does little impact on output file size), that I use for a few years now, and they never caused any problem to me. My files are 40K max.
> 
> I believe that line of code has no direct relation to Optlink crash, but I still post it just to show that it's code simplification that leads to crash, not adding any new type or symbol or anything.
> 
> Thanks for any hint.

I guess this is just a random instance of OPTLINK's bug. I recommend 
sacrificing your firstborn.

Or if that doesn't work, change the order in which you pass modules to 
the compiler - certain symbols (template instantiations, initializers, 
classinfo, etc) will end up in different object files and that might hit 
OPTLINK's sweet spot.

And/or compile some modules without -g. Maybe you don't need debug 
symbols everywhere.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode