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
