<div dir="ltr">Hello, <br><div><div class="gmail_extra"><br><div class="gmail_quote">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">Hi Jan,<br>
<span class=""><br>
On 4 July 2016 at 14:12, Jan Ciger <<a href="mailto:jan.ciger@gmail.com">jan.ciger@gmail.com</a>> wrote:<br>
> It was a fresh checkout from Github master from a few minutes ago. I have<br>
> modified the main CMakeLists.txt and added /bigobj, as mentioned in the<br>
> error message, to CMAKE_CXX_FLAGS for MSVC and now the same code seems to<br>
> build fine,so that doesn't look like a corrupted file. I was building a<br>
> debug build when I have got that error, not sure whether it has any<br>
> relevance.<br>
<br>
</span>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>
What size are the object files and resulting osgdb_gles.dll?<br></blockquote><div><br><br></div><div>The OpenGLESGeometryOptimizer.obj is 4.84MB in Release and 28.81MB in Debug, the remaining files are few hundred kB (Release), few megs (in Debug).<br><br></div><div>The DLL is 770kB in release and 3.84MB in debug. <br><br></div><div>I have noticed that the incremental linking was off in the CMakeLists.txt for MSVC, that could perhaps have an impact.<br></div><div><span class=""></span><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>Can the option just been added to the gles pugin if absolutely required?<br></blockquote><div><br></div><div>Yes, possibly. However, it may be that the build would break elsewhere too - I didn't have time to rebuild the whole mess several times today, so I have put it only globally. I don't think that the GLES code is somehow special. <br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Right now, it seems pretty odd that the gles plugin would break some<br>
compiler limits that we've never hit before in any other module or<br>
plugins, so I'm inclined to think there is something specific going<br>
on, perhaps a bug with the compiler that is throwing things off.<br></blockquote><div><br></div><div>Yes, I wouldn't be surprised. Or it could be triggering generation of ton of code in 2015 that exceeds the limits. MSVC 2015 broke a lot of code that was compiling before, because it is both stricter and updated for newer C++ standard. So when rebuilding older C++ code I am now often troubleshooting compilation failures about code referencing deleted functions, template problems, you name it. <br><br></div><div>J.<br></div></div></div></div></div>