Hi Mark,<br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 5:42 PM, Mark Sciabica <span dir="ltr"><<a href="mailto:msciabica@itracs.com">msciabica@itracs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The versioning of the dll's doesn't completely solve the problem. I have customized OSG for my application, changing the public interface in a way such that the objects are not binary compatible with vanilla OSG. Linking dll's without my customizations can cause crashes. I install my customized build into a private directory in an attempt to avoid this problem. However, this "feature" thwarts my efforts.</blockquote>
<div><br>I do hope you are publishing these changes to the core OSG, this is a requirement of the OSGPL/LGPL.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

And this problem affects more than just those who customize OSG. On Windows, we also need to contend with compatibility between builds from different compiler versions, and compiler options (e.g. linking debug vs. release or static vs dynamic runtime libraries). If two applications are installed, both using OSG 2.8.0, they need to be built with the same compiler version and same options or problems will ensue as they use the same path to load plugins.</blockquote>
<div><br>If you have incompatible versions then you should bump the SO version number to avoid contention.<br><br>Robert. <br></div></div><br><br>