<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Hello again, <br></div><div class="gmail_quote"><br>On Mon, Jul 4, 2016 at 4:29 PM, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Weird.  I have just had a look t the source file the compiler is<br>
complaining about and it looks pretty standard.<br>
<br>
The gles plugin on Linux is not particularly large either. I can't see<br>
any obvious reasons why there would be any need for some special<br>
options.<br>
<br></blockquote><div><br></div><div>This is what the doc says about /bigobj:<br><a href="https://msdn.microsoft.com/en-us/library/ms173499.aspx">https://msdn.microsoft.com/en-us/library/ms173499.aspx</a><br><br></div><div>My suspicion is that as that optimizer code works over all possible OSG nodes, it is possible it is trying to instantiate ton of templates (e.g. osg::ref_ptr<>), pushing the number of sections over 64k in my particular case, with my set of self-compiled dependencies. <br><br></div><div>It seems that adding /bigobj should be safe, only compilers older than MSVC 2005 wouldn't be able to deal with such object files - which is a non-issue, because one cannot really mix C++ object files/libs between MSVC versions safely anyway.<br></div><div><br></div><div>J. <br><br><br></div></div></div></div>