Robert Osfield wrote:
Hi Mark,
On Tue, Mar 24, 2009 at 5:42 PM, Mark Sciabica <[email protected]
<mailto:[email protected]>> wrote:
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.
I do hope you are publishing these changes to the core OSG, this is a
requirement of the OSGPL/LGPL.
We have not yet reached our first release so it's not yet an issue.
However there's nothing secret about our changes as I've already posted
them to the mailing list (and had them ignored or rejected).
Exception #2 of the license allows binary distribution of "works based
on the Library" "under the user's own terms". I will encourage my
employer to make our changes available to users if they request them,
but it does not appear to be a requirement of the license of the core OSG.
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.
If you have incompatible versions then you should bump the SO version
number to avoid contention.
Where do I configure the SO version number, and how does it restrict
which plugins are loaded?
I don't think this addresses the general problem handling the
coexistence of builds using different compiler versions or build options
(e.g. different settings for OSG_USE_FLOAT_MATRIX). Should everyone use
a different SO version number? Should we just accept that multiple
installs of OSG may not work on a single machine?
I can easily fix this problem for my build. I brought up this issue to
try to help improve OSG for others. If you're convinced this is an
acceptable design for handling plugin loading despite this issue, I will
just leave it at that.
Regards,
Mark
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
